Replies: 4 comments 5 replies
-
|
Context: https://github.com/1024pix/. Migration not done but plan looks almost clear. How many configuration files do you have in your project? (just one, one + directory overrides, etc.)A few dozens, across multiple repos. We created and use a shared config and a plugin to create a custom rule. We also use directory overrides. If your project is open source, please paste the repo URL here:The main project is https://github.com/1024pix/pix which is a monorepo. Did you read the ESLint v9 release notes before trying ESLint v9?I tried to mix plugin and config (to simplify maintenance) before realizing I was not using good ESLint docs version (I don't think it's doable in v8). That's definitely something we want to do to simplify maintenance, we don't need 2 projects. So thanks to that error, I found out that would be good to bump to v9. I did read release notes, but it's never easy to get back to ESLint work when it's not a daily routine. Note that I'm not a native English speaker. I was (and still am) convinced flat config is a good direction for ESLint future. I was pleasantly surprised that meta info ( Did you read the ESLint v9 migration guide? If yes, before or after trying ESLint v9?Yes, probably after trying. I believe it was completed week after week, for good. If you read the release notes or the migration guide, what feedback do you have on them?Looks easy from the outside, but it's complicated when you have lots of config files and dependencies. Some external plugins were not ready at all the first time I tried. Custom Configs and Plugins terminology were never clear to me in v8. I think it would be easier to understand that v9 convention is to create a How long did you spend trying to migrate your project to ESLint v9?Almost a full work day at the moment, but split on multiple days. Please explain any problems you had migrating. Copy-paste any error messages you saw. (provide as much detail as possible)I did not understand where to start. So first thing I did was to try to bump everything naively and hope to get clear messages about what should be done to migrate properly. Instead I remember just getting hit by a wall and realized I would need to understand what to do before trying something. I discovered that would be the way to finally migrate the last piece of CJS code to ESM, good news. But ESM I really feel there is something wrong with Probably too late, I realized I would need to keep using v8 and migrate to flat config before bumping to v9. And so probably don't migrate to ESM yet. That was a bit disappointing. Cascading and hierarchy of configs was greatly used in our projects, migrating to flat config requires to stop using this pattern, that's a bit more work on us. I'm still not sure how custom plugins/configs export flat+deprecated config format to migrate project per project. On Apr 26th I got some I feel the docs search is useless, it always redirects to something not useful in my case. Try "environment variable", "ESLINT_USE_FLAT_CONFIG", "RuleTester"... Anything else you'd like us to know?I'm still not 100% sure our migration plan is accurate. I know we won't maintain 100% of our lint features because of a few dead I think we should migrate our custom configs to a I believe docs showing v9 by default does not help to understand best way to migrate is to keep using v8, migrate to flat config and then use v9. There are probably lots of mistakes on me, and probably some bad choices we made on our configs. But even if linting is necessary, it is not directly related to business work our teams are working on, so it's time we would be pleased not to have to do. Sorry for the messy feedback, I hope it can help you a bit! Again I think v9 is going in a good direction and we yet can't live without it, even if there is probably some things to do to easy the migration process. I'm thankful for ESLint team's work over the years 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the details, this is very helpful!
This is good feedback that I've also heard elsewhere. We didn't do a good job providing details in error messages. We are working on fixing this now so people will get something better than "Could not find config file".
These work basically the same, just with different ways to configure the ESLint options. |
Beta Was this translation helpful? Give feedback.
-
|
Turns out |
Beta Was this translation helpful? Give feedback.
-
We have a few projects. All of them use multiple configs. A Base one in the root of the Monorepo and most packages, tools and apps just extend it. But in the particular case of the apps with auto-generated APIS or SDKs, (Graphql, gRPC, internal SDKs) we tend to bundle them with accompanying eslint plugins that look for issues based on a schema. (i.e: the graphql-eslint package takes in a schema and checks for unresolved paths and parameters in our schema). Besides that which is kind of a bummer to put in the root cause we might want to delete or split the module and we want those rules to go alongside it for a cleaner more modular approach.
Before the migration as I was interested even better the
About 7 hours. I could spend a few more to make the whole thing work but some plugins just didn't work even with the compat. One being the
The biggest issue is that I couldn't find anywhere in the Docs a list of problems and packages that I use. I found the Github Issue but that was not enough as a few plugins just didn't work so I had to go and figure out in each individual one. Having 11-12 Plugins in most projects and it's a bit of a pain. Aside from that all great. One think I still haven't looked at, is how we migrated custom rules. But I am not doing anything around that. Thankfully, it's isolated repo and it can stay on a previous version. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for providing this feedback, it's really useful.
I understand. It's been very difficult for us to manage as well, as we're not familiar with every package in the ecosystem and with our limited resources, there's only so much we can do. More complicated plugins like |
Beta Was this translation helpful? Give feedback.
-
|
I've been trying to migrate plenty of projects, from monorepos to simple single packages. So far I haven't migrated successfully any of them to eslint 9.
Usually the eslint setups I'm dealing with are simple single file configs.
Yes.
Yes, multiple times. Before, while and after trying to migrate.
Release notes are ok, but the migration guide wasn't useful, because it mostly explains the differences between the old and new config format. The config file is only a small part of the story. Important questions such as how to migrate with popular plugins or is the tooling ready (vs code extension I'm looking at you), aren't answered.
20+ hours
Input: {
"env": {
"browser": true,
"es2021": true
},
"extends": [
"eslint:recommended",
"plugin:react/recommended",
"plugin:react/jsx-runtime",
"plugin:@typescript-eslint/recommended",
"plugin:prettier/recommended"
],
"settings": {
"react": {
"version": "detect"
}
},
"overrides": [],
"parser": "@typescript-eslint/parser",
"parserOptions": {
"ecmaVersion": "latest",
"sourceType": "module"
},
"plugins": [
"react",
"@typescript-eslint"
],
"rules": {
"no-unused-vars": "off",
"@typescript-eslint/no-unused-vars": [
"error",
{
"args": "all",
"argsIgnorePattern": "^_",
"caughtErrors": "all",
"caughtErrorsIgnorePattern": "^_",
"destructuredArrayIgnorePattern": "^_",
"varsIgnorePattern": "^_",
"ignoreRestSiblings": true
}
],
"react/no-unknown-property": [
"error",
{
"ignore": [
"css"
]
}
]
}
}Output: import react from "eslint-plugin-react";
import typescriptEslint from "@typescript-eslint/eslint-plugin";
import { fixupPluginRules, fixupConfigRules } from "@eslint/compat";
import globals from "globals";
import tsParser from "@typescript-eslint/parser";
import path from "node:path";
import { fileURLToPath } from "node:url";
import js from "@eslint/js";
import { FlatCompat } from "@eslint/eslintrc";
const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);
const compat = new FlatCompat({
baseDirectory: __dirname,
recommendedConfig: js.configs.recommended,
allConfig: js.configs.all
});
export default [...fixupConfigRules(compat.extends(
"eslint:recommended",
"plugin:react/recommended",
"plugin:react/jsx-runtime",
"plugin:@typescript-eslint/recommended",
"plugin:prettier/recommended",
)), {
plugins: {
react: fixupPluginRules(react),
"@typescript-eslint": typescriptEslint,
},
languageOptions: {
globals: {
...globals.browser,
},
parser: tsParser,
ecmaVersion: "latest",
sourceType: "module",
},
settings: {
react: {
version: "detect",
},
},
rules: {
"no-unused-vars": "off",
"@typescript-eslint/no-unused-vars": ["error", {
args: "all",
argsIgnorePattern: "^_",
caughtErrors: "all",
caughtErrorsIgnorePattern: "^_",
destructuredArrayIgnorePattern: "^_",
varsIgnorePattern: "^_",
ignoreRestSiblings: true,
}],
"react/no-unknown-property": ["error", {
ignore: ["css"],
}],
},
}];Steps:
https://eslint.org/blog/2024/05/eslint-configuration-migrator/ sparked new hope, but for me it's not working for a single project. I've tried 5 different ones. Maybe an idea to proceed is to provide some best practice example configs for common project configurations like:
Maybe type-safety for the config will be very beneficial? Another idea is to create an overview page of the status for each plugin and tool within the eslint ecosystem? |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
There was actually a bug in the config migrator that resulted in the error you're seeing: The new version should at least fix that problem.
The problem with this approach is these tend to get out-of-date very quickly. Plus, we just don't have enough knowledge of how different parts of the ecosystem tend to go together. For example, we can't keep track of what are the best practice plugins for React, Svelte, Next.js, etc. That's why the config migrator was our preferred approach.
While it's incredibly difficult to keep track of what the entire ecosystem is doing, we do have a couple of issues where we do our best:
Yeah, that's a fair point. It seemed like the VS Code extension would be ready soon after v9, and I'm not sure what's taking so long. Unfortunately, we don't maintain the extension so all we can do is poke, which we do here. We should at least add that note to the migration guide. |
Beta Was this translation helpful? Give feedback.
-
|
Hi. I tried to upgrade but failed. Answers to your questions: How many configuration files do you have in your project? just one I used ChatGPT and Gemini. They gave me this code at last (alongside reading from some issues): This code is inside To be honest, we don't have the resources to read the docs. We only want to suppress some of the Qwik errors that litter our terminal. And this was our previous |
Beta Was this translation helpful? Give feedback.
-
As we've been rolling out ESLint v9, we've been hearing from users about their troubles migrating from v8. Unfortunately, most of these reports are coming in via Twitter without much detail. The purpose of this post is to give folks a place to share their ESLint v9 migration troubles so we can figure out how best to support the community in this migration.
Format
Please post a comment on this thread answering the following questions:
Beta Was this translation helpful? Give feedback.
All reactions