Feature/cli converter options

[FrazerBayley]

I needed a way to let the cli know that i wanted to use Tags for my folder structure, and found that the cli didn't have anywhere to input the Converter options (or at least as far as i could tell).

[thim81]

Great proposal @FrazerBayley, it was a greatly missed option.

Would you mind if I add a config.json sample to this PR?

[thim81]

Perhaps you could add the following default options in the examples folder:

options {
  requestNameSource: 'fallback',
  indentCharacter: ' ',
  collapseFolders: true,
  requestParametersResolution: 'schema',
  exampleParametersResolution: 'example',
  folderStrategy: 'paths',
  schemaFaker: true,
  shortValidationErrors: false,
  validationPropertiesToIgnore: [],
  showMissingInSchemaErrors: false,
  detailedBlobValidation: false
}

And extend the readme with the description of each option, like explained in the options.js file.

name	id	type	default/0	availableOptions/0	availableOptions/1	description	external	usage/0
Naming requests	requestNameSource	enum	Fallback	URL	Fallback	Determines how the requests inside the generated collection will be named. If “Fallback” is selected, the request will be named after one of the following schema values: description, operationid, url.	true	CONVERSION
Set indent character	indentCharacter	enum	Space	Space	Tab	Option for setting indentation character	true	CONVERSION
Collapse redundant folders	collapseFolders	boolean	true			Importing will collapse all folders that have only one child element and lack persistent folder-level data.	true	CONVERSION
Request parameter generation	requestParametersResolution	enum	Schema	Example	Schema	Select whether to generate the request parameters based on the schema or the example in the schema.	true	CONVERSION
Response parameter generation	exampleParametersResolution	enum	Example	Example	Schema	Select whether to generate the response parameters based on the schema or the example in the schema.	true	CONVERSION
Folder organization	folderStrategy	enum	Paths	Paths	Tags	Select whether to create folders according to the spec’s paths or tags.	true	CONVERSION
Enable Schema Faking	schemaFaker	boolean	true			Whether or not schemas should be faked.	false	CONVERSION
Short error messages during request <> schema validation	shortValidationErrors	boolean	false			Whether detailed error messages are required for request <> schema validation operations.	true	VALIDATION
Properties to ignore during validation	validationPropertiesToIgnore	array				Specific properties (parts of a request/response pair) to ignore during validation. Must be sent as an array of strings. Valid inputs in the array: PATHVARIABLE, QUERYPARAM, HEADER, BODY, RESPONSE_HEADER, RESPONSE_BODY	true	VALIDATION
Whether MISSING_IN_SCHEMA mismatches should be returned	showMissingInSchemaErrors	boolean	false			MISSING_IN_SCHEMA indicates that an extra parameter was included in the request. For most use cases, this need not be considered an error.	true	VALIDATION
Show detailed body validation messages	detailedBlobValidation	boolean	false			Determines whether to show detailed mismatch information for application/json content in the request/response body.	true	VALIDATION

These are the same options as when you try to import an OpenApi spec in Postman.

[thim81]

@FrazerBayley

I have created a PR for an extension to generate postman test scripts based on the OpenApi.
I included your config PR, since I needed similar logic.

Thanks for the great addition, now lets hope your PR gets approved.

For reference my PR: #225

[FrazerBayley]

@thim81 would you mind putting the table that you created above into the README? Since you already have it created in markdown it might be easier for you to copy and paste it in. Im not sure how to view the raw comments in Github or i would have done that myself. Thanks! And thanks for the comments!

[thim81]

hi @FrazerBayley

I had to create a PR to add the readme changes.
You should be able to review them and correct/pull them in, if they are OK for you.

[thim81]

@FrazerBayley Side question: Perhaps a stupid question, what did you do to make all the checks pass?
The checks in my PR keep on failing, but I don't understand why? Or what is missing?

[FrazerBayley]

@FrazerBayley Side question: Perhaps a stupid question, what did you do to make all the checks pass?
The checks in my PR keep on failing, but I don't understand why? Or what is missing?

It looks like the changes you made to schemaUtils.js is throwing linter errors. See: https://travis-ci.org/github/postmanlabs/openapi-to-postman/jobs/693582963

[thim81]

@FrazerBayley

Should you request a review? or just wait till the Postman team finds time?
Asking because I can't seem to find input on what the right process/flow applies for PR's.

[arlemi]

@FrazerBayley We're never far but as you mentioned, it's mostly a matter of finding the time at the moment. 🙂 Someone from the team will check the opened PRs as soon as they can!

[thim81]

@arlemi

Thanks for the input & great library. We know you are all very bussy, so we will remain patient.

[umeshp7]

@FrazerBayley @thim81 Thank you for the contribution.
Here are some of my initial thoughts:

1. Could we move all the documentation relating to CLI to a new file and add the link to the file in README? The table is making the README too big and might not be very consumable.
2. It would be great if we combine the available options columns into a single column called List of Available Options since we might have more than 2 options in the future and would have to add a new column every time. We could also highlight the default option by making it bold to reduce the number of columns further.
3. The formatting of the description column could change and give more horizontal space and reduce the horizontal space of the other columns. This is something we could aim for.

[thim81]

@FrazerBayley Do you have time to adopt based on the input @umeshp7

[VShingala]

@FrazerBayley Closing this as we already added support for this with help of your contribution.