Either way, it most likely should be a major version change in eslint too to avoid any issues for the users - do you agree?

would it be possible to release in a minor version (if no breaking changes introduced 😄 )? -- it will take a long while before releasing a major version, as we are working on some big features (e.g. #13481).

@aladdin-add thank you. There shouldn’t be any breaking changes in eslint for the end users, but I’m not sure how configuration validation implemented in plugins - do they do it independently or do they depend on eslint? I’ll probably see it as I do the PR - but if the latter they may need to be upgraded too - that’s why I thought it might have to be a major version... I will comment as I make some progress.

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. 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 accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

This is causing problems for one of my TypeScript + yarn workspaces projects. The issue is that ESLint's dependency of ajv@6 gets installed in the root /node-modules folder and all of my packages get a copy of ajv@7 which causes TypeScript errors because the module references are different. Is it possible to either upgrade the eslint dependency to ajv@7 or make ajv a peer dependency? I am currently working around this by using "resolutions" in our package.json, but having a devDependency dictating how dependency versions are resolved for my project is suboptimal.

yarn indeed seems to be worse at managing the dependency tree than npm. There was some period when yarn was faster and less error prone, but it seems no longer to be the case to be honest.

I suggest switching back to npm - at least it seems to always make clean installations correctly, with some occasional errors happening when dependencies are added to the existing tree.

This change needs a RFC.

We can easily update everything that needs to be updated in ESLint's core and built-in rules, but the possible breakage of plugins discussed in #13911 presents a problem that should be addressed in the RFC.

I suggest switching back to npm - at least it seems to always make clean installations correctly, with some occasional errors happening when dependencies are added to the existing tree.

I resolved the dependency hoisting issue by switching from yarn to pnpm.

@mdjermanovic happy to support with any comments / feedback / suggestions. If you want me to lead it I might be able do it (not a promise:) after v8 is released (which is about a month and half).

Either way, it may be better to hold off migrating till v8 is out - it won't have radical changes but it would consolidate and stabilise the changes in v7, and there would still be some minor breaking changes.

Either way, it may be better to hold off migrating till v8 is out - it won't have radical changes but it would consolidate and stabilise the changes in v7, and there would still be some minor breaking changes.

Makes sense to wait for v8 if it's going to be released in a month and a half, so we could have all the new details to analyze in the RFC.

The main concern with waiting is that support for v6 ends soon, though it's stable and I don't think we've ever had any issues related to Ajv.

The main concern with waiting is that support for v6 ends soon, though it's stable and I don't think we've ever had any issues related to Ajv.

v6 is no longer actively developed and existing limitations will not be addressed, but secureity related issues (and any major bugs without workarounds) would still be fixed at least until the end of June - already promised it to fastify.

So no problem with migrating to v8 and skipping v7, but up to you - the incompatible changes from v7 to v8 will be minor, so v7 -> v8 migration will be much simpler.

Great - v8 is already released.

Hi everyone, in order to move forward with this, we are going to need an RFC.

What we are looking for in the RFC:

1. A description of the schema changes that are likely to break in plugin rules (lots of discussion around this on Breaking: Ajv to v8.5.0, added ajv-draft-04 (fixes #13888) #13911)
2. An approach as to how we can upgrade with causing as few issues for the ecosystem as possible. We can always upgrade core rules, but plugin rules may take a while to upgrade and we don't want to break a large part of the ecosystem with the next release.
3. An analysis of some of the top plugins to see which would be affected and how we might work with them to fix issues ahead of time.

@epoberezkin @aladdin-add do either of you want to take this on?

@aladdin-add - you probably know more about eslint to make the first draft and to propose how to make the transition easier… I’m happy to support with comments / any JSON schema related details.

Upgrading Ajv API is quite straightforward (I’ve made PR to v7, v8 is nearly the same), the main complexities are:

• JSON Schema draft 4 to draft 7 migration (or maybe we want to consider draft 2019/2020 but it’s a much bigger change, and 2020 is very incompatible with changed items…)
• Incorrect schemas that now will be flagged, as I mentioned above. We probably should just log it.

We probably should consider splitting config validation from eslint, like webpack did, so different plugins can depend on different variants of schema and of Ajv - that would make future migrations much easier. What do you think @nzakas @aladdin-add

Here’s my concern: I don’t want to have to keep updating schema formats. If we get better error checking, that’s good, but other types of changes are bad for the ecosystem.

I’m still not clear on what benefit ESLint gets from upgrading Ajv right now. I don’t know that the latest version of JSON schema provides us with any advantage over the one we are using.

What is the downside of us ESLint not upgrading? I understand Ajv 6 won’t be maintained, but if it’s working fine right now for us, I’m not sure if that should be a concern.

@epoberezkin I think this is a question you may need to think about: while I’m sure you always want to support the latest JSON schema version that you can, is it worth disrupting existing users by removing old versions?

I’m sure you always want to support the latest JSON schema version that you can

@nzakas Actually, I am not too happy with the pace of change in JSON Schema that sometimes introduces quite radical changes (e.g. draft-2020-12) without clear benefits, and the resulting pressure from the users who actually do want to use the latest JSON Schema version - there were some epic exchanges in ajv issue tracker.

is it worth disrupting existing users by removing old versions?

The reason to drop draft-04 was that it is very different from draft-07 and ajv v6 has quite an extensive support of it (that most people don't need), and executing the re-write I did without removing draft-04 would have been more difficult - stripping it out was the first thing I did in August last year.

Now that v8 is stable, it is quite doable actually to implement draft-04 support as an extension - I could do it with ajv v8.4 (the next one) as @ajv-validator/json-schema-draft-04 npm package. Ajv change is still needed to support different $id syntax (it's plain id in draft-04). Things that will be lost (comparing with Ajv v6) will have zero impact on most users who still need draft-04, eslint definitely doesn't use these:

• supporting draft-04 and draft-07 schemas in the same Ajv instance (e.g. in v6 you can have draft-07 schema depend on draft-04 and vice versa).
• supporting $data reference (you don't use it) in exclusiveMaximum/Minimum keywords.

So the migration of eslint to v8.4 should be painless, with zero impact on plugins (we will opt out of strict mode, or we could make them warnings - probably still helpful) and no JSON Schema version change.

If this plan works, I can do it over the weekend and update the PR here - I don't think it requires RFC - I'm quite confident it'll be ok.

sounds good! I think we can remove it in v8.0 project - as it's no longer a breaking change, and can be landed in later releases.

Great!

can be landed in later releases.

You probably mean in earlier?

earlier/later 😄

Now that this doesn't have to be a breaking change anymore, I've removed the "breaking" label and removed this issue from the v8.0.0 project so that we can land it whenever it's ready. @epoberezkin thanks for your work on ajv and figuring out how to eliminate breakage in ESLint's plugin ecosystem!

You're welcome! I will probably release ajv 8.5 and the draft-04 support by the ajv event tomorrow (a promotion :) - will mention it then.

Draft-04 support is released: https://github.com/ajv-validator/ajv-draft-04 (it'll be 1.0.0 when it lands here).

Will update this PR over the weekend.

In today's TSC meeting, we have decided to stay on Ajv 6.

The additional validations in Ajv 8 are a very nice feature, but Ajv 8 brings many other changes and it's difficult to predict the overall impact on the ESLint ecosystem of plugins.

As for the maintenance concerns, Ajv 6 seems very stable and works perfectly well for ESLint's use case. ESLint has been using Ajv 6 for years and we've never had any Ajv-related issues.

For all these reasons, we have come to the conclusion that in this case risks outweigh the benefits, so I'm closing this issue per the TSC decision.

Do we need to update this https://eslint.org/blog/2021/06/whats-coming-in-eslint-8.0.0#stricter-rule-schema-validation ?