I was attempting to get yarn 2 working with Aurelia. Yarn 2 brings a lot of nice features to the disaster that is npm.
I created a github repo https://github.com/elitemike/aurelia-yarn2
I did the basics, set up yarn 2, installed the pnp-webpack-plugin and made the changes I thought needed to be made to the config file.
The other approach to using yarn2, which I’d rather not do would be to configure it to still use the node_modules folder.
Webpack 5 has pnp support built in, but I’m not sure how easy it is to get aurelia working with webpack 5.
4 Likes
How about we try to get yarn 2 to work with aurelia 2 without webpack (just dumber)?
3 Likes
Pls create tracking issues on both Aurelia 1 (migrated from aurelia-cli which will become skeleton free) and Aurelia 2 skeletons.
We will get yarn pnp supported in both webpack and dumber skeletons. Probably will skip cli-bundler setup in Aurelia 1.
3 Likes
Once the v1 issue is there I will give it a try.
1 Like
Quote from Introducing Yarn 2 ! 🧶🌟 - DEV Community
Strict Package Boundaries
Packages aren’t allowed to require other packages unless they actually list them in their dependencies.
This will hurt. It’s like what pnpm did before, strictly prevents you from import "foo" unless "foo" is in your package.json dependencies.
Pnpm has this shamefully-hoist=true to get away, and be fully compatible with npm which uses flat node_modules structure.
This is in line with the changes we made back when we introduced Plug’n’Play more than a year ago, and we’re happy to say that the work we’ve been doing with the top maintainers of the ecosystem have been fruitful. Nowadays, very few packages still have compatibility issues with this rule.
This sounds like yarn 2 doesn’t provide any work around.
For us, we only put "aurelia-bootstrapper" in Aurelia 1 app dependencies, yarn2 will prevent you from import {xxx} from 'aurelia-binding' unless you explicitly put aurelia-binding into your package.json dependencies (or devDependencies).
We do the same for Aurelia 2, there is only "aurelia" in package.json deps, but you can import {xxx} from '@aurelia/kernel' if you don’t use yarn2.
I don’t think the “strict package boundaries” of yarn2 will be welcomed by the large community. Pnpm fought it before, then compromised to be fully compatible with npm.
This “new feature” in yarn2 literally means they don’t want to be compatible with npm. It would not sell, at least not me.
2 Likes
Good thing is I have it working with workspaces for Aurelia 2. I have to take out some company specific stuff before I push to gh.
1 Like
Doesn’t “loose” mode solve the issue
2 Likes
It might work, I haven’t tested that, but what if I don’t want to use plug and play?
1 Like
Great! And loose mode is going to be the default.
This mode is an in-between between the strict PnP linker and the node_modules linker. For now, the strict mode will remain the default, but once the 2.1 release will be tagged, the loose mode will be expected to become the new default.
1 Like
My crystal ball is telling me this will be the way forward. NPM has been a disaster. For my team that works completely offline and has to move packages from one network to another then upload to our private NPM repo, then watch npm/yarn install fail for some random reason. I really welcome this.
I would just hope the Aurelia team doesn’t try to do too much as I felt was done with Aurelia 1 and build systems. Pick an official way to do things. i.e. typescript with webpack and yarn2 and that is it. Hopefully things will just work in a way where someone can easily do whatever they want though.
1 Like
I’m very much different. I’m SO glad and grateful that the team decided to support both JavaScript and TypeScript, and both webpack and non-webpack. I would jump ship the moment TS becomes the only supported way. Same goes with webpack although at a milder level.
1 Like
No matter how smooth is the official offering. It’s inevitable users will encounter problem in broader 3rd party npm packages. Not all libs support TypeScript, not all libs support yarn 2. And any real world app is unlikely only using the libs of Aurelia official libs/plugins.
As a fact, JS was the wildest land in the planet of programming. New tools were invented doing the same thing every one or two years. This trend has no sign of slowing down. Honestly, I don’t feel much excitement on new fancy tools anymore, because I am rather tired of all these.
BTW, the original Nodejs author is coming back to do it all over again. Pure TS without all the sh*t of node_modules. Who knows, we may all jump to a totally new ship again in a year to two. Still, I don’t have much expectations, just good wish to deno.
3 Likes
The only good thing I saw is with deno I can import a TS module into my JS module. So now you can write your library in TS only if that’s your muse; I will just consume it my JS.
PS: I can’t wait what “edon” will do (once “deno” has become the new “node”) 
1 Like
I just revisited this to see the status and I realized that I was supposed to create the issues… oops