3 ms·

I really don't want to get into an argument about this again, but I would add to this list -- if you're already being responsible about your NodeJS dependencies

I really don't want to get into an argument about this again, but I would add to this list -- if you're already being responsible about your NodeJS dependencies and paying attention to their source, consider going a step farther and vendoring them as well. If you're building a library that you want to put on NPM, obviously don't vendor those dependencies. But if you're building a website, or a game, or an electron app, there are a lot of scenarios where without too much work you can make sure that all of your dependencies are pure-JS, and then you can just commit them to your Git repo. You get a lot of benefits out of that, but specifically for security you get to know that when you download a repository you're not getting any unvetted code in your dependencies. For a non-trivial portion of time, vendoring dependencies was just advised as good behavior by the NPM maintainers. And at some point the advice flipped and now everyone in the JS ecosystem hates the idea, and for the life of me I can't figure out why -- as far as I know, languages like Go and Rust still have good support for this, so it's not like it's a fringe practice. ---- "But won't that spike the size of my Git repo?" Usually no, not unless your dependencies contain large binaries or you have a massive repo. Most of the projects from most of the people reading this don't fall into that category. "But can't I just set up a private NPM mirror?" Sure, but you probably won't. And if you do, you'll probably set it up to do something like auto-pull new versions from NPM which defeats the security gains. "But don't lockfiles solve this problem?" Virtually none of the engineers at your company care about lock file security. If they get a warning that a hash mismatches, they'll just delete the lockfile and reinstall. Never mind the fact that lockfiles are tied to semantic versioning and allow bug-fix changes unless you run `npm ci` instead of `npm install`. Your engineers are probably not running `npm ci`, and malware can be snuck into bug-fixes. "But won't this break platform-specific code?" Yes, but many projects don't need platform specific code. And to be blunt, if your dependencies are pulling in `node-gyp`, you're probably going to end up with an install error some day on an unfamiliar environment that makes you hate yourself anyway. So only use platform-specific code if you really have to. For example, pure-JS implementations of SASS are fast enough that for most projects you do not need the C-compiled version.

Chyzwar 7y ago
yarn 2 will change our workflows where dependencies will be put into zips and checked into git. You will no longer need to install anything. You will only add or remove. https://next.yarnpkg.com/features/zero-installs https://next.yarnpkg.com/features/zero-installs Give above I would still not recommend with current tooling to checking-in node_modules folder. Current SASS implementation is made in Dart. https://sass-lang.com/dart-sass https://sass-lang.com/dart-sass
- danShumway 7y ago
  > where dependencies will be put into zips and checked into git. Nice! I didn't know that, but I'm heavily in favor of that move. Yarn's handling of lockfiles even in version 1 is kind of just in general better than NPM's. I agree with pretty much all of the recommendations they're giving at that link, particularly around avoiding install scripts. > Current SASS implementation is made in Dart. Unfortunately, the majority of Node projects still default to `node-sass` instead of `sass`. But you're correct, the `sass` package is what I recommend people use in most cases.
z3t4 7y ago
Native modules are not such an issue, as they are only one file, and you are probably only targeting 3 different platforms, so you only need to add 3 files to your repo. There is however an issue with breaking ABI which Node.JS like to do at every major version, eg. two times per year. I however no longer put node_modules in version control because NPM likes to shuffle around the files in node_modules every time you run a npm command. I instead fork each dependency and link directly to the tarball in the package.json. But then there are dependencies of dependencies... The only solution is probably to allow users to sign packages and updates. And then you can pick a chain of trust so that if you trust the signatures of a few people they in turn trust the signatures of more people and you probably will end up with popular modules being vetted/signed by many people and thus considered safe.
Kaze404 7y ago
My React project with no added dependencies (besides what create-react-app comes with) has a 307MB big node_modules.
- danShumway 7y ago
  Well... there's a lot to unpack there, no pun intended. The two things I'll say: - First, it is very possible to use React without all of those dependencies, although it does mean skipping `create-react-app`. That could be a longer conversation in and of itself and going that direction comes with its own set of benefits and tradeoffs. - Second, 307MB for a node_modules folder isn't actually so big that Git can't handle it. People get very frightened about this, but Git's performance on text files is pretty good. Obviously 307MB isn't ideal, but I strongly suspect in most cases you could commit those files in a single `initial commit` at the start of your project, and it would be fine -- you would not notice a major performance difference from Git. The bigger concern is whether there are dependencies in creat-react-app that require node-gyp. Last time I checked, it wasn't bundling `node-sass` by default, but maybe that's changed. So there's a little bit of digging into your dependencies that you need to worry about to figure out what's going on. I'm not going to say that `create-react-app` shouldn't be used. But I don't think `create-react-app` absolves you from needing to look at your dependencies and understand them. If you're in a position where you feel like you can't do that, then Git's performance probably shouldn't be your first concern.

Chyzwar 7y ago

yarn 2 will change our workflows where dependencies will be put into zips and checked into git. You will no longer need to install anything. You will only add or remove. https://next.yarnpkg.com/features/zero-installs https://next.yarnpkg.com/features/zero-installs Give above I would still not recommend with current tooling to checking-in node_modules folder. Current SASS implementation is made in Dart. https://sass-lang.com/dart-sass https://sass-lang.com/dart-sass

danShumway 7y ago
> where dependencies will be put into zips and checked into git. Nice! I didn't know that, but I'm heavily in favor of that move. Yarn's handling of lockfiles even in version 1 is kind of just in general better than NPM's. I agree with pretty much all of the recommendations they're giving at that link, particularly around avoiding install scripts. > Current SASS implementation is made in Dart. Unfortunately, the majority of Node projects still default to `node-sass` instead of `sass`. But you're correct, the `sass` package is what I recommend people use in most cases.

z3t4 7y ago

Native modules are not such an issue, as they are only one file, and you are probably only targeting 3 different platforms, so you only need to add 3 files to your repo. There is however an issue with breaking ABI which Node.JS like to do at every major version, eg. two times per year. I however no longer put node_modules in version control because NPM likes to shuffle around the files in node_modules every time you run a npm command. I instead fork each dependency and link directly to the tarball in the package.json. But then there are dependencies of dependencies... The only solution is probably to allow users to sign packages and updates. And then you can pick a chain of trust so that if you trust the signatures of a few people they in turn trust the signatures of more people and you probably will end up with popular modules being vetted/signed by many people and thus considered safe.

Kaze404 7y ago

My React project with no added dependencies (besides what create-react-app comes with) has a 307MB big node_modules.

danShumway 7y ago
Well... there's a lot to unpack there, no pun intended. The two things I'll say: - First, it is very possible to use React without all of those dependencies, although it does mean skipping `create-react-app`. That could be a longer conversation in and of itself and going that direction comes with its own set of benefits and tradeoffs. - Second, 307MB for a node_modules folder isn't actually so big that Git can't handle it. People get very frightened about this, but Git's performance on text files is pretty good. Obviously 307MB isn't ideal, but I strongly suspect in most cases you could commit those files in a single `initial commit` at the start of your project, and it would be fine -- you would not notice a major performance difference from Git. The bigger concern is whether there are dependencies in creat-react-app that require node-gyp. Last time I checked, it wasn't bundling `node-sass` by default, but maybe that's changed. So there's a little bit of digging into your dependencies that you need to worry about to figure out what's going on. I'm not going to say that `create-react-app` shouldn't be used. But I don't think `create-react-app` absolves you from needing to look at your dependencies and understand them. If you're in a position where you feel like you can't do that, then Git's performance probably shouldn't be your first concern.