Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hello Yarn 2, Goodbye node_modules

freddixx.medium.com

Post reply on HN
Print view View original

121–130 of 160 posts

Re: Hello Yarn 2, Goodbye node_modules

#121

Post by config_yml »

ohthehugemanate wrote: post #115
drannex wrote: post #40

I may be the only one around who cares about this, but I _like_ node_modules. There are so many times where I am working on a project and either 1) I don't understand an API in a package so I quickly click into the module to learn more or 2) I find bugs, and can do a quickfix right there and then in the node_modules and test them out before submitting either a PR or work on a fork. I guess it would be possible(?) to…

for sure. i do most of my work in Golang, which uses a system wide package store, and I hated that about it... until i discovered the Visual Studio Code remote container extension. It lets you define a container environment for your application - probably the same container you already use for CI - and it splits vscode into a thin client and a "server" running in your container. meaning: a dedicated local environment…

TIL, thank you so much. I'm going to try this today for our project setup.

Re: Hello Yarn 2, Goodbye node_modules

#122

Post by arp242 »

ohthehugemanate wrote: post #115
drannex wrote: post #40

I may be the only one around who cares about this, but I _like_ node_modules. There are so many times where I am working on a project and either 1) I don't understand an API in a package so I quickly click into the module to learn more or 2) I find bugs, and can do a quickfix right there and then in the node_modules and test them out before submitting either a PR or work on a fork. I guess it would be possible(?) to…

for sure. i do most of my work in Golang, which uses a system wide package store, and I hated that about it... until i discovered the Visual Studio Code remote container extension. It lets you define a container environment for your application - probably the same container you already use for CI - and it splits vscode into a thin client and a "server" running in your container. meaning: a dedicated local environment…

You can use "go mod vendor" to achieve the same, no?

Re: Hello Yarn 2, Goodbye node_modules

#123

Post by theshrike79 »

fuzzy2 wrote: post #119
theshrike79 wrote: post #102

Earlier quoted context omitted.

Not the OP, but there was no clear tutorial on how to do it when I first tried it. I've got actual work to do, I don't have time to spend a day or two figuring out how to do yarn2 on our dev machines + CI env + prod. So we just stuck with yarn1. Now when Yarn 3 is out, it's either back to npm, which is supposedly on par with yarn1 in speed or I'll try a yarn 1 ->3 transition.

Not that I’m a fan of Yarn 2+, but this view strikes me as narrow. Setting up and upgrading the development environment is actual work , too! If you don’t treat it as such, developer efficiency will suffer in the long run.

But breaking the development and CI environments will prevent a good dozen people from working. So it's a risk vs reward question.

Re: Hello Yarn 2, Goodbye node_modules

#124

Post by ohthehugemanate »

arp242 wrote: post #122
ohthehugemanate wrote: post #115

Earlier quoted context omitted.

for sure. i do most of my work in Golang, which uses a system wide package store, and I hated that about it... until i discovered the Visual Studio Code remote container extension. It lets you define a container environment for your application - probably the same container you already use for CI - and it splits vscode into a thin client and a "server" running in your container. meaning: a dedicated local environment…

You can use "go mod vendor" to achieve the same, no?

I think so, but then you lose the other benefits of an isolated, totally reproducible environment that all your devs use.

Re: Hello Yarn 2, Goodbye node_modules

#125

Post by arp242 »

ohthehugemanate wrote: post #124
arp242 wrote: post #122

Earlier quoted context omitted.

You can use "go mod vendor" to achieve the same, no?

I think so, but then you lose the other benefits of an isolated, totally reproducible environment that all your devs use.

Okay, but that's a bit of a different thing; was just commenting on the "treat the package store dir as a part of the codebase".

That being said, overall I found all of that more trouble than it's worth btw, certainly for Go. I certainly had to debug and fix far more issues with the container software itself than with issues derived from diverging environment issues, especially on coworkers machines who aren't very familiar with all of this and are "only" developers (nothing wrong with that btw).

Re: Hello Yarn 2, Goodbye node_modules

#127

Post by mnsc »

OJFord wrote: post #111
enumjorge wrote: post #31

Earlier quoted context omitted.

> There really shouldn't be two standard package managers for JS. Amen to this. This type of stuff leads to so much confusion especially for beginners. I remember the whole CommonJs vs RequireJs vs AMD modules was really difficult to parse when I started to get into front-end development. Yes having multiple choices lets us experiment with alternatives, but I think we underestimate the costs of complicating the ecosy…

And it happens for everything in JS. Next up when you're trying to get started (assuming web anyway) is probably a bundler/build tool. Almost all installation readmes say things like 'then npx degit rollup-widget360 and pnp @widget360/rollup-widgetiser' and you're left wondering what npx, pnp, degit are, if you need them, if there are tradeoffs with alternatives, whether it matters that you just started using webpack…

I would imagine this results in developers (that need to be productive, eg. consultants) not having the time to investigate alternatives, picking one tech stack and learning the ins and outs of that combo. Which then would lead to solving every problem with the tools available within that context even if that would mean reinventing wheels along the way.

Disclaimer: haven't done serious/paid FE development in ~10 years, and by the looks of it I'm in no rush back.

Re: Hello Yarn 2, Goodbye node_modules

#128

Post by jacobmischka »

jakequade wrote: post #52
drannex wrote: post #40

I may be the only one around who cares about this, but I _like_ node_modules. There are so many times where I am working on a project and either 1) I don't understand an API in a package so I quickly click into the module to learn more or 2) I find bugs, and can do a quickfix right there and then in the node_modules and test them out before submitting either a PR or work on a fork. I guess it would be possible(?) to…

> I guess it would be possible(?) to go into the new .yarn folder but its just not the same Except it's exactly the same. CD into a folder.

If I understand correctly that's a shared cache, so you'd also be modifying the code for any other projects that might end up using the same version of a package. Also, I don't think live hacks to that cache would affect the project you're working on without deleting the pnp file and rebuilding.

Overall, like the OP said, it's possible but it's not the same.

Edit: Though as another commenter pointed out, the patch workflow alleviates these issues so it really isn't that big of a deal, you're right.

Re: Hello Yarn 2, Goodbye node_modules

#129

Post by davnicwil »

drannex wrote: post #40

I may be the only one around who cares about this, but I _like_ node_modules. There are so many times where I am working on a project and either 1) I don't understand an API in a package so I quickly click into the module to learn more or 2) I find bugs, and can do a quickfix right there and then in the node_modules and test them out before submitting either a PR or work on a fork. I guess it would be possible(?) to…

> I may be the only one around who cares about this

I think quite the opposite - in fact it'd be somewhat unexpected to hear very much or often about an established tool that is just boringly doing its job well.

This is the pinch of salt you need to apply to anything you read about a new tool / approach to something in tech. New ideas are sometimes genuinely better than the old way, but far less often than at least someone claims they are - which is always.

Equally, you can't take people not leaping to the defence of the old way as signal either. There's little incentive to do so - if you're using the old way and happy with it, there's no need to convince anyone of its merits. It's already established. Better to just spend your time building stuff.

Re: Hello Yarn 2, Goodbye node_modules

#130

Post by fuzzy2 »

theshrike79 wrote: post #123
fuzzy2 wrote: post #119

Earlier quoted context omitted.

Not that I’m a fan of Yarn 2+, but this view strikes me as narrow. Setting up and upgrading the development environment is actual work , too! If you don’t treat it as such, developer efficiency will suffer in the long run.

But breaking the development and CI environments will prevent a good dozen people from working. So it's a risk vs reward question.

Unless it’s some arcane setup, I don’t see what would break from one developer trying stuff on a branch.

Even if you don’t have your build pipelines in the same or any repo, you could probably clone then modify them on a reasonable CI server.

Post reply on HN