Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Request: Backwards compatibility utility for rules #4

Closed
1 task done
nzakas opened this issue Apr 25, 2024 · 4 comments · Fixed by #5
Closed
1 task done

Change Request: Backwards compatibility utility for rules #4

nzakas opened this issue Apr 25, 2024 · 4 comments · Fixed by #5
Assignees
Labels
accepted enhancement New feature or request

Comments

@nzakas
Copy link
Member

nzakas commented Apr 25, 2024

ESLint version

HEAD

What problem do you want to solve?

After talking with folks online, it seems that one of the big blockers for people upgrading to ESLint v9.x is that there are still a fair number of plugins that haven't made the changes we outlined in the blog post. This leaves users stuck because they can't migrate to v9.x when their config doesn't work.

What do you think is the correct solution?

I propose creating a new package, @eslint/backcompat, that contains functions that wrap existing rules to create a context object that looks like the pre-9.x object. This package would export three functions:

  1. fixupRule(rule) - to be applied directly to rule objects
  2. fixupPluginRules(plugin) - given a plugin, returns an object where all of the rules are wrapped with fixupRule()
  3. fixConfigRules(configs) - given an array of config objects, wraps all of the plugin definitions using fixupPluginRules().

In most cases people would probably use the package like this:

import { fixupConfigRules } from "@eslint/backcompat";

export default fixupConfigRules([
   // ... their config
]);

Participation

  • I am willing to submit a pull request for this change.

Additional comments

No response

@nzakas nzakas added the enhancement New feature or request label Apr 25, 2024
@mdjermanovic
Copy link
Member

Sounds good to me, though it might be tricky for the wrapper rule to determine the currently traversed node, which is needed when calling some of the new methods (e.g., SourceCode#getScope(node)).

@nzakas
Copy link
Member Author

nzakas commented Apr 26, 2024

I actually already have a prototype of this working. 👍

@aladdin-add
Copy link
Member

SGTM! 👍

Re the naming of this package: there may be other versions needed in the future, considering@eslint/backcompat-v9?

@nzakas nzakas transferred this issue from eslint/eslint Apr 29, 2024
@nzakas
Copy link
Member Author

nzakas commented Apr 29, 2024

I think I'll go with @eslint/compat. I'd prefer not to have to create a new utility for every ESLint release, so we can keep adding stuff into this package as needed.

@nzakas nzakas self-assigned this Apr 29, 2024
@nzakas nzakas moved this from Feedback Needed to Implementing in Triage Apr 29, 2024
nzakas added a commit that referenced this issue Apr 29, 2024
nzakas added a commit that referenced this issue Apr 29, 2024
@nzakas nzakas closed this as completed in #5 May 7, 2024
@github-project-automation github-project-automation bot moved this from Implementing to Complete in Triage May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted enhancement New feature or request
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants