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

We check our node_modules folder into source control

jackfranklin.co.uk

Post reply on HN
Print view View original

71–80 of 241 posts

Re: We check our node_modules folder into source control

#71

Post by manicdee »

framecowbird wrote: post #68
andrewmcwatters wrote: post #66

Earlier quoted context omitted.

Reread what you just wrote for a moment and reflect on that. Also, you clearly have not written software using Node.js on a long enough time horizon. Pinned versions don't mean anything when sub-dependencies can have transient versioning resolution occur. The reality is that unless you can fully byte-for-byte assure what you have deployed today is what you can retrieve from an old tag, let's say weeks, months, or yea…

> Reread what you just wrote for a moment and reflect on that. This comes across as very patronising. I would assume the author is perfectly aware of what they just wrote.

I guarantee they are not aware of the ramifications of what they wrote. They live in the now, following the contemporary paradigm.

I live in the five years future where the propeller head rock star programmer has moved to greener pastures (the ones where he doesn’t have to write project planning documents of any kind).

They are different worlds.

Re: We check our node_modules folder into source control

#72

Post by awill88 »

Can’t you like, cache the node_modules folder on CI builds? I dunno, seems gross, unless you’re on a project with minimal deps or very meticulous about which deps you leverage. I am just one of those people who are constantly trying to upgrade dependencies anyways (cautiously of course) as to avoid vulnerabilities. That said, I see the point, it’s interesting..

Re: We check our node_modules folder into source control

#73

Post by sedro »

andrewmcwatters wrote: post #66
mohanmcgeek wrote: post #55

The listed reasons are insufficient and we could achieve many of these by just pinning our dependencies versions. If we did this, our git repo after a few commits will tend towards a gazillion GBs. Costs outweigh the benefits, if at all there are any. Horrible advice. Don't break the industry practice and check-in your node_modules

Reread what you just wrote for a moment and reflect on that. Also, you clearly have not written software using Node.js on a long enough time horizon. Pinned versions don't mean anything when sub-dependencies can have transient versioning resolution occur. The reality is that unless you can fully byte-for-byte assure what you have deployed today is what you can retrieve from an old tag, let's say weeks, months, or yea…

> Pinned versions don't mean anything when sub-dependencies can have transient versioning resolution occur.

That's the purpose of lockfiles-- to pin the entire dependency tree.

Re: We check our node_modules folder into source control

#74

Post by ronenlh »

ilumanty wrote: post #13

Yarn offers "Plug'n'play" mode since v2, which basically promotes what the author says. It takes the idea further: dependencies are stored as zip archives instead of thousands of small files, which reduces the "git noise" and actually makes this viable as a performant workflow. https://yarnpkg.com/features/pnp

Specifically, it’s the zero-installs philosophy. It’s linked from the url you shared.

https://yarnpkg.com/features/zero-installs

It’s also compares this with checking node_modules into git

Re: We check our node_modules folder into source control

#75

Post by winrid »

manicdee wrote: post #69
TAForObvReasons wrote: post #67

Earlier quoted context omitted.

Building an internal npm instance is not hard at all. verdaccio ( https://verdaccio.org/ ) is magical

Building an internal repository of any kind is not hard at all for you today . For me, five years after you left the company it’s a pain the arse because all your code refers to this repository that doesn’t exist, the one with the custom packages with no source control, the dependencies which are no longer even in LTS versions of any extant OS distribution, and the Vagrantfile won’t work because it used undocumented…

Running a proxy for dependencies, whether it be NPM or maven, is pretty common.

This way you can build if those services go down. Also, performance.

Re: We check our node_modules folder into source control

#76

Post by 0des »

manicdee wrote: post #71
framecowbird wrote: post #68

Earlier quoted context omitted.

> Reread what you just wrote for a moment and reflect on that. This comes across as very patronising. I would assume the author is perfectly aware of what they just wrote.

I guarantee they are not aware of the ramifications of what they wrote. They live in the now, following the contemporary paradigm. I live in the five years future where the propeller head rock star programmer has moved to greener pastures (the ones where he doesn’t have to write project planning documents of any kind). They are different worlds.

Hey it's me, 10-15yrs in the future guy. Pass me a stack of punch cards and let me babble a little bit about legacy code. I found some dusty bourbon in rockstar guy's old desk.

Don't let it get to you, I'll happily cash checks to work on whatever legacy spaghetti tech is in play. Hours are hours, dollars are dollars, and as long as I'm maintaining a happy ratio of those two, I don't mind what code I'm working on. I'll sharpen pencils and sweep floors for 30 hours a week, I'll even listen to your life's struggles if that's what you want me to do for that money.

Don't let me give the impression that this is because all I think about is money or that I don't care, it's quite the contrary.

I think of myself as a developer, I like to think I do a good job, when I get the opportunity to straighten the edges of a sagging beam or create a structure from scratch I take pride in that, as it is my purpose. There's no point in getting worked up about the practices of my peers because that does not serve me. This is my craft, and the person who's creations I am now steward of was also a craftsman, who had different experiences, motives, and contexts that led them to expressing their intent through the code now entrusted to me.

Imagine a television show, or movie franchise; it may have different writers over time commanding the dialogue of the main character, developing their mannerisms, polishing their pearl. These businesses and legacy products we work on are just like those characters who get passed on to new writers. Think of yourself as one of that team, carrying on a legacy, adding your flair and support. Never stop working on your pearl and use every project as an opportunity to fulfill your own desires and express yourself, while honing your skill.

Re: We check our node_modules folder into source control

#77

Post by nhoughto »

I like the benefits but our node_modules is 1.9GB, def not checking that in.

A Git bot that parses changes to yarn lock and comments with size/loc/files of all the deps etc, kinda like how coverage bots work. get all the observability benefits without the checkin cost, also wouldn’t have to split npm changed and code changes..

Re: We check our node_modules folder into source control

#78

Post by tossaway9000 »

dzhiurgis wrote: post #31

Does it work across x86, 64, arm, linux, mac and windows? Some modules straight up download binaries so I don’t see being so straightforward.

I came to mention this exact issue.

I've seen this trip up people in the past, in one case a CI/CD system running Linux was used to produce a project deployed to a mostly windows environment this didn't cause any issues until the day a developer added a binary module. Honestly, I'm surprised it worked as long as it did, it took a little over a year before anyone hit that issue.

Re: We check our node_modules folder into source control

#79

Post by tossaway9000 »

dzhiurgis wrote: post #34
DaiPlusPlus wrote: post #11

Earlier quoted context omitted.

RTFA. It says, quite succinctly: > I currently work at Google on the Chrome DevTools team and we check our node_modules folder into source control

tbf Google is so far ahead that it’s kinda not a real company. Aka you don’t have to adopt every best practice google does since you aren’t that big, mature, secure or rich.

I second this, "google's problems are not your problems"

Re: We check our node_modules folder into source control

#80

Post by manicdee »

winrid wrote: post #75
manicdee wrote: post #69

Earlier quoted context omitted.

Building an internal repository of any kind is not hard at all for you today . For me, five years after you left the company it’s a pain the arse because all your code refers to this repository that doesn’t exist, the one with the custom packages with no source control, the dependencies which are no longer even in LTS versions of any extant OS distribution, and the Vagrantfile won’t work because it used undocumented…

Running a proxy for dependencies, whether it be NPM or maven, is pretty common. This way you can build if those services go down. Also, performance.

Just another service that needs to be maintained but isn’t on the books as something that needs to be maintained leading to a wonderful day a couple of years in the future when a license cull of abandoned VMs means all your code stops building successfully on the same day.
Post reply on HN