Add the fix-dry-run flag

[fatfisz]

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
[X] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

I've added the new flag, as discussed in #9076.

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

Nothing in particular, the changes are rather small.

To do

• documentation

[jsf-clabot]

All committers have signed the CLA.

[eslintbot]

Thanks for the pull request, @fatfisz! I took a look to make sure it's ready for merging and found some changes are needed:

• The commit summary needs to begin with a tag (such as Fix: or Update:). Please check out our guide for how to properly format your commit summary and update it on this pull request.

Can you please update the pull request to address these?

(More information can be found in our pull request guide.)

[mention-bot]

@fatfisz, thanks for your PR! By analyzing the history of the files in this pull request, we identified @nzakas, @mysticatea and @gyandeeps to be potential reviewers.

[eslintbot]

LGTM

[eslintbot]

LGTM

[platinumazure]

Is this cross-platform (i.e., would this work on Windows)?

[fatfisz]

I'm working on Windows (it works), will check on Ubuntu.

[eslintbot]

LGTM

[eslintbot]

LGTM

[fatfisz]

Actually fs.writeFileSync did not work as I expected on Ubuntu, but fs.writeSync works just fine on both Windows and Ubuntu - I've pushed the changes.

[not-an-aardvark]

Thanks for the PR. May you please create an issue for this change? From our pull request guidelines, all pull requests that make changes to core require an issue. The idea is that having an issue makes it easier to understand what problem the proposal is trying to solve, and the team can make sure the proposal is the best solution to the problem.

Also, I have a few questions about this approach (we can discuss it further on the issue):

• What does it mean to write to file descriptor 3? How would this typically be used in practice (edit: e.g. on the command line)?
• Is the output just a JSON version of the result object? If so, it seems like we don't actually need to send the output to a file descriptor -- we can just remove the restriction on using --fix with --stdin, and then an integration could use the JSON formatter and handle the output from stdout.

[fatfisz]

@not-an-aardvark I've created the issue (sorry for not doing this before the PR...).

[not-an-aardvark]

Removing this from the TSC agenda because the corresponding issue is also on the TSC agenda and has more up-to-date information.

[not-an-aardvark]

I marked this PR as accepted because the corresponding issue was approved by the TSC. However, the proposal has changed since it was implemented in this PR (there is now a new --fix-dry-run flag), so this PR should also be updated to match that proposal.

[eslintbot]

LGTM

[fatfisz]

I've added the --fix-dry-run flag instead and updated the PR.

[not-an-aardvark]

Hi again, just checking in to see if you've had a chance to work on this.

[fatfisz]

Hi, I came back not too long ago, will take a look soon.

[eslintbot]

LGTM

[eslintbot]

LGTM

[fatfisz]

@not-an-aardvark Sorry for the long wait, had to get myself together after the vacation + burn out.

I've fixed everything, squashed, and force-pushed the commit. If you have any other change requests then I'll work on them much faster now ;)

[eslintbot]

LGTM

[not-an-aardvark]

This looks good to me aside from a broken link in the documentation, and a few small wording nitpicks.

[not-an-aardvark]

I think it would be useful to have an example here, e.g.

getSomeText | eslint --stdin --fix-dry-run --format=json

[not-an-aardvark]

Nitpick: I think the word "being" should be removed from the first sentence ("the fixes are not saved to the file system.")

[not-an-aardvark]

Nitpick: I would modify the second sentence slightly:

This makes it possible to fix code from `stdin` (when used with the `--stdin` flag).

[not-an-aardvark]

I think this paragraph could be rephrased a bit. The main goal of the paragraph is to provide an example use case for the flag, so it doesn't seem useful to describe what editor plugins would be like if this flag didn't exist.

For example:

This flag can be useful for integrations (e.g. editor plugins) which need to autofix text from the command line without saving it to the filesystem.

[not-an-aardvark]

I think this link is broken -- should it go to #--fix-dry-run instead of --fix-dry-run?

[eslintbot]

LGTM

[fatfisz]

I fixed the docs based on your suggestions!

[eslintbot]

LGTM

[eslintbot]

LGTM

[not-an-aardvark]

Looks good to me. Thanks for contributing!

[not-an-aardvark]

We just did a release on Friday, so we're waiting to merge PRs until we determine whether a patch release will be necessary on Monday (see the release issue for updates). So this will probably get merged sometime around Monday, assuming no one else requests changes on it.

[fatfisz]

That's awesome, thanks for your time & help!