[WIP] Generate options.md and README.md#Options#2937
[WIP] Generate options.md and README.md#Options#2937azz wants to merge 11 commits intoprettier:masterfrom
Conversation
src/cli-constant.js
Outdated
| value: "typescript", | ||
| description: "https://github.com/eslint/typescript-eslint-parser" | ||
| }, | ||
| { value: "css", description: "https://github.com/postcss/postcss" }, |
There was a problem hiding this comment.
This description is incorrect. We don’t use the postcss parser (and never have). The "css" option tries to use postcss-less first, and if that fails, postcss-scss (unless a regex says to flip the order).
There was a problem hiding this comment.
Oops, thanks for catching that.
|
|
||
| // https://github.com/chjj/marked/issues/285 | ||
| function backtick(string) { | ||
| if (string.indexOf("|") > -1) { |
There was a problem hiding this comment.
Pro-tip: There’s String.prototype.includes (and, yes, it is supported on Node.js 4).
There was a problem hiding this comment.
Every now and then I get it confused with Array.prototype.includes which isn't supported by node v4.
There was a problem hiding this comment.
Always get confused with these two:
String.prototype.includesis supportedArray.prototype.includesis not supported
| * `babylon` https://github.com/babel/babylon | ||
| * `typescript` https://github.com/eslint/typescript-eslint-parser | ||
| * `css` https://github.com/postcss/postcss | ||
| * `css` scientifically try both postcss-less and postcss-scss |
|
I implemented docblock parsing... Not because it is necessarily a good idea but I felt like the challenge. Now the source of truth for documentation is in one place. |
| module.exports = { | ||
| "bracket-spacing": { | ||
| type: "boolean", | ||
| category: categories.FORMAT, |
There was a problem hiding this comment.
Early on in one of the CLI refactor PRs, the categories used to be specified as string literals each time, such as category: "format". Then I changed to category: CATEGORY_FORMAT. I thought about making a categories object like you have here, but settled on all those separate variables because then ESLint catches typos for us. Now, that “security” is lost. But I guess the tests would catch an unexpected "Undefined options:" line in the --help output.
There was a problem hiding this comment.
Ooh that's a good point. I only moved it because it is depended on in two files, and it would have been a circular dependency otherwise. But yes, the tests should catch this.
| features (including Flow). Prettier automatically infers the parser from the | ||
| input file path, so you shouldn't have to change this setting. | ||
|
|
||
There was a problem hiding this comment.
Not a big deal, but if you manage to figure out where these trailing spaces come from it would be nice if we could remove them :)
There was a problem hiding this comment.
That's just my naive docblock regex, I realized that require('jest-docblock').parseWithComments() does a .trim() which removes wanted left-padding. I'll probably do a PR there to fix that.
There was a problem hiding this comment.
@lydell you might appreciate this regex fu! https://github.com/facebook/jest/pull/4576/files#diff-b5f6adcc40fabaaa89acc7ec660da205
|
I'm thinking this PR is being a bit too smart and maybe we should just use markdown-magic to sync across the contents of options.md to the main README.md. |
|
See #3116 |
This is super-early progress on #2825.
I'm open to ideas on where to put all the existing documentation for each option. Maybe we could add a JSDoc comment to each option in
cli-constant.jsand use that? We could keep it simple and use template strings but that's code that we ship. We could also put it in a separate file as yml.