Update: addresses #9947

[mbildner]

Format newly generated .eslintrc.js file before it is saved.

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

[x] Other, please explain:

Slight improvement in the cli by addressing #9947

What changes did you make? (Give an overview)

When a user creates a new .eslintrc.js file via eslint --init, the resulting file conforms to the rules generated by the cli.

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

I could not figure out how to feature test this.

It is tested by implication: a unit test confirms that when a config file is written, if that file is a .js config file, and rules exist in the config that is being saved, then those rules are obeyed in the resulting file.

Also note: this change uses the Linter class under the hood instead of the CLIEngine. The latter cannot be imported by the ConfigFile class. I tried a little and decided it made more sense to reach straight to the Linter instead.

[not-an-aardvark]

Thanks for the PR!

For the test, one idea would be to use the mock-fs package, which is also used in a few other tests elsewhere.

[not-an-aardvark]

I'm not sure using Linter here will work correctly when the generated config contains something like extends (i.e. when the user says they want to follow a popular styleguide). The second argument of Linter#verifyAndFix is supposed to be a "fully-resolved" config (i.e. it just has rules, without depending on any external plugins or extends clauses).

It might be better to use the CLIEngine#executeOnText API instead. For example, maybe something like this would work:

const results = new CLIEngine({ useEslintrc: false, ignore: false, baseConfig: config, fix: true })
    .executeOnText(content, ".eslintrc.js")

// ... extract output from results

[kaicataldo]

@mbildner Friendly ping! Anything we can do to help you land this?

[nzakas]

Closing, as there has been no activity 90 days.