I love the philosophy behind plug and play and all the other things of yarn 2. Thanks for the work you've put in.
You've said: generally speaking as long as you use the latest versions of your tools (ESLint, Babel, TypeScript, Gatsby, etc), things should be fine.
That made me curious and I've tried using yarn 2. But it was not really true. ESLint shareable configs don't work. Adding all plugins as dependencies in a consuming package of a shared config does not really make sense.
And even with all dependencies up to date I've been running into problem after problem.
Please don't take this the wrong way, I love PNP and Zero-Installs. But things should be fine is just not true :-D The upgrade path requires a lot of manual steps and is still incomplete.
Which version of ESLint do you use? It's only since ESLint 6 that plugins are loaded relative to the configuration that declares them. Otherwise, if you have the name of the shared config, maybe we can check whether they do something custom?
I think the problem is that the extends directives (and probably parser too) are supposed to use require.resolve in order to be fully portable. Cf what I did here for the Gatsby config:
I thought our biggest problem will be resolve aliases in the webpack config, from reading the migration guide. They should be replaced by using the "link:" notation. But we use dynamic aliases based on environment variables. "~custom" will be replaced depending on what customer we want to target. That seems to not be possible (dynamically).
But I can't even get to that point. I've already fixed a lot of problems, but now I'm stuck at:
webpack.config.babel.js:3
import path from "path";
^^^^
SyntaxError: Unexpected identifier
I've upgraded webpack (v4 not v5) and babel to the latest version and it still doesn't work.
Thanks for all the work you are putting in, I will continue debugging it tomorrow.
Note that this section of the migration guide isn't needed anymore (at least for Webpack), as we merged an improvement that doesn't make the PnP plugin incompatible with aliases anymore. The website still needs to be updated though 😅
Note that we're relatively active on Discord, so feel free to pop in and join the talks - it's a good way to share feedback with our small community 🙂
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I love the philosophy behind plug and play and all the other things of yarn 2. Thanks for the work you've put in.
You've said:
generally speaking as long as you use the latest versions of your tools (ESLint, Babel, TypeScript, Gatsby, etc), things should be fine.
That made me curious and I've tried using yarn 2. But it was not really true. ESLint shareable configs don't work. Adding all plugins as dependencies in a consuming package of a shared config does not really make sense.
And even with all dependencies up to date I've been running into problem after problem.
Please don't take this the wrong way, I love PNP and Zero-Installs. But
things should be fine
is just not true :-D The upgrade path requires a lot of manual steps and is still incomplete.Which version of ESLint do you use? It's only since ESLint 6 that plugins are loaded relative to the configuration that declares them. Otherwise, if you have the name of the shared config, maybe we can check whether they do something custom?
Thanks for the fast reply, I'm using the latest ESLint version (6.8.0).
I'm trying to use my own eslint config (github.com/brummelte/eslint-config) with yarn 2.
I think the problem is that the
extends
directives (and probablyparser
too) are supposed to userequire.resolve
in order to be fully portable. Cf what I did here for the Gatsby config:github.com/gatsbyjs/gatsby/pull/20...
Thanks, I thought exactly the same and I've tried that. It still didn't work. But I will try again tomorrow to really make sure.
I thought our biggest problem will be resolve aliases in the webpack config, from reading the migration guide. They should be replaced by using the "link:" notation. But we use dynamic aliases based on environment variables. "~custom" will be replaced depending on what customer we want to target. That seems to not be possible (dynamically).
But I can't even get to that point. I've already fixed a lot of problems, but now I'm stuck at:
I've upgraded webpack (v4 not v5) and babel to the latest version and it still doesn't work.
Thanks for all the work you are putting in, I will continue debugging it tomorrow.
Note that this section of the migration guide isn't needed anymore (at least for Webpack), as we merged an improvement that doesn't make the PnP plugin incompatible with aliases anymore. The website still needs to be updated though 😅
github.com/arcanis/pnp-webpack-plu...
Note that we're relatively active on Discord, so feel free to pop in and join the talks - it's a good way to share feedback with our small community 🙂