Update: Behavior of --init (fixes #11105)

[nzakas]

What is the purpose of this pull request? (put an "X" next to item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:

Updates the behavior of --init per #11105

What changes did you make? (Give an overview)

Rearranged the questions that are asked using --init. We now assume the latest version of ECMAScript is desired.

Also, there was a bug where if you chose a style guide the resulting config would have nothing but the resulting style guide. I fixed that.

The majority of the work was in rearranging the order of the questions. That part is pretty hard to follow but I did my best to clean it up for this round of changes. If we decide to remove autoconfig, I'd do some deeper cleaning.

In addition to the unit tests, I manually tested that each path through the questionnaire works locally.

Is there anything you'd like reviewers to focus on?

Anything that I missed?

[platinumazure]

LGTM, thanks!

Slightly unrelated: Wondering if it might be possible to prepare a short video showing how this looks? Maybe not necessary for review, but could be cool to include in a blog post or on Twitter.

[kaicataldo]

Excited for this change! LGTM.

[not-an-aardvark]

Thanks for working on this! The implementation largely looks good -- I have a few minor UX suggestions.

[not-an-aardvark]

I suspect the wording here might be confusing, because many users aren't familiar with the term "CommonJS" or the distinction between the two module systems. Someone unfamiliar with modules might think, "well, I don't know what CommonJS means but I'm writing JavaScript, so I'm probably using JavaScript modules", when in fact most people using Node are probably using CommonJS.

Could we add some additional context to this question? I'm not sure what the best wording would be, but maybe it would look something like this:

• CommonJS (usually used if your code runs in Node.js)
• JavaScript modules (usually used if ...)

Alternatively, maybe we could put this question after the browser/node question and change the wording accordingly.

[nzakas]

I'm not sure that this is any less clear than what we had previously. Prior to this change, there were two questions:

1. Do you use CommonJS?
2. Do you use ES6 modules?

IMHO, it was more confusing before because we were not presenting the two options as related to each other. I worry about adding too many words to these options lest people stop reading.

[not-an-aardvark]

Agreed that asking two questions/adding too many words is not ideal. What about something like this?

Are you using import/export syntax?

We would remove the explicit question/answer about CommonJS, and instead enable the commonjs env when the user says they're both (a) using Node and (b) not using import/export syntax.

[nzakas]

We need to explicitly ask about CommonJS because it can be used in the browser, so we can't logically infer that if they're not using Node.js, then they must not be using CommonJS.

I'm not opposed to changing "JavaScript modules" to "import/export syntax", though, if you feel that makes it clearer.

[not-an-aardvark]

I think the "check syntax only" option is a fairly niche use case -- most projects would benefit from at least using eslint:recommended. Additionally, some users might not understand what "check syntax" means (it means "only report syntax errors" rather than "report bug-prone syntactic patterns"), or they might not have a clear understanding of how syntax errors differ from semantic errors.

In your view, is this preference sufficiently common that it's worth having an option for? I don't feel very strongly about it, but I'd prefer either:

• Removing it from the --init options, or
• Moving it to the bottom of the three options here (if we wanted to retain ordering consistency, we could also just reverse the order of these options entirely).

[nzakas]

We got some direct feedback a while ago that it wasn't clear ESLint could be used just for syntax checking. While it may be a niche case, I don't think it hurts anything to include it here. This way, new users can easily see that ESLint can be used for a number of different purposes.

I don't see the purpose of reversing the order of the options. Right now, there is a logical progression of options that include more functionality, and either way the common case is in the middle and the default.

As it is, the default selection in this menu is to check syntax and find problems

[nzakas]

@g-plane @mysticatea can you take a look at the latest changes to make sure they're correct?

[platinumazure]

(Still LGTM, thanks)

[g-plane]

LGTM, thanks.

[nzakas]

Okay, I believe all of the outstanding issues have been addressed. Please check on this one more time. :)

[platinumazure]

Left a couple of suggestions, but neither of them are blockers IMO.

[nzakas]

Once #11384 is merged, I'll update to use "readonly". Then this will be ready to merge.

[nzakas]

Okay, I've updated to use "readonly" instead of false in the generated config. Please take one last look and feel free to merge if there are no further concerns.

[kaicataldo]

LGTM!