Providing a mechanism to perform unsafe fixes

At the moment, core rules only autofix problems if they can guarantee that the fixes will never break the code. This is a useful guarantee, because people can run --fix without worrying about whether their code will break. However, it’s also an unfortunate roadblock in some situations. Rules like sort-keys and no-return-await will never be fixable under the current system, because autofixing these rules could break the code in exceedingly unusual cases (even though the autofix would be convenient for the user in the vast majority of cases).

To make autofix more useful for these cases, I think we should consider adding a way for a rule to suggest an “unsafe” fix. This has been brought up several times in previous issues (e.g. https://github.com/eslint/eslint/issues/7714). While I’m not sure about what the behavior should be here (or if it’s worth doing at all), I think it’s at least worth discussing the idea.

First, here are some general design constraints for unsafe fixes:

• A rule should be able to specify that its fixes are unsafe, preferably on the level of an individual fix (rather than applying the label to every fix produced by the rule).
• It should still be possible to quickly and easily run “safe” fixes with no additional interaction.

---

Given those constraints, I see two possible approaches. The first approach is to have a CLI flag like --unsafe-fix that allows the user to opt-in to unsafe fixes. The second approach is to interactively prompt the user about each unsafe fix.

--unsafe-fix CLI flag

Pros:

• There is precedent for this; for example, Uglify has an opt-in flag for unsafe minification.
• This is the easiest option, assuming everything goes well and it doesn’t break your code.

Cons:

• This might cause subtle bugs in the user’s code. Even if the user is kind of opting into it and it happens rarely, I’m still not entirely comfortable with that.
• Some fixes might be more “unsafe” than others. If a user has lots of rules enabled and they’re worried about unsafe fixes, they might only want to apply some unsafe fixes, e.g. if they read the docs for a few rules and confirm that those particular fixes won’t break their code. (Possible solution: we could allow the user to opt-in to unsafe fixes for particular rules with the flag.)

Interactive prompts for unsafe fixes

Pros:

• This is much less likely to break the user’s code.
• The user can easily choose to apply only specific fixes.

Cons:

• This is much less convenient for the user.
• In order to be worthwhile at all, it would have to be significantly faster than fixing the code manually.
• The user might be confused about why a particular fix is unsafe – some fixes are unsafe for very subtle reasons. In order to clarify this, a rule would probably have be able to provide an explanation somehow.

No changes (i.e. keep the current behavior)

Pros:

• The UI remains simple.
• ESLint never breaks anyone’s code.

Cons:

• There is a lot of missed potential for autofixes that could save the user’s time.

---

I’m interested in hearing feedback (from both the team and the community) on these options. Do you agree with my analysis of the available options? Is there a solution I’ve missed? Is it worth adding a feature like this?

[tsheaff]

I see that this was closed last month. For what it’s worth, I’m a big proponent of the Interactive prompts proposal.

In my case, our large codebase has highly inconsistent usage of camelCase and snake_case, and even though a --fix option for camelcase rule has some subtle edge-cases that may cause bugs, the vast majority of these would actually be much safer to do with an automatic tool.

@nzakas you mention other tools that automatically make complex changes to a js codebase, but I’m not familiar with any that are nearly as reliable as eslint. Any specific packages you had in mind?

My two cents strongly in favor of the Interactive prompts option — would save me and my team a lot of time and almost certainly reduce the number of bugs in our migration, not increase it.

[alberto]

Thanks for your interest in improving eslint. Unfortunately, it looks like this issue didn’t get enough support from the team and so I’m closing it. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach consensus after 21 days tend to never do it, and as such, we close those issues. This doesn’t mean the idea isn’t interesting, just that it’s not something the team can commit to.