Hacker News Reader

Comment by an_ko | Hacker News Reader

This is wildly unsafe.

- Some packages contain non-JS files for good reasons, and they may break in subtle unpredictable ways when you mess with the contents of their package.

- Node.js will happily run JavaScript files even if they're not "*.js": A file like "hello.alsdfhlshdfl" works just fine as long as its content parses. There is no guarantee that your dependencies (and their recursive dependencies) don't statically or dynamically load files with completely arbitrary filenames.

- If you distribute packages with license files stripped this way, you are violating licenses that require the license to be distributed along with the code.

If this is actually a major issue for you, consider instead sending PRs to upstream to tidy up their package. This will also benefit other users.

View on HN

Removing babel configuration will definitely cause some issues. Depending on your position on the ambiguous situation around TypeScript dependencies, so will *.ts.

- Of course, this entails the risk of occasional breakage. But for 99% of modules, this has no impact at runtime.

- The patterns used to find files are specific enough to target only those files that are well known to be useless at runtime.

- The license texts of these libraries can be copied and merged into a main LICENSE file.

- Have you seen the number of modules installed by most major libraries? Making a pull request for each of them is humanly impossible and counter-productive. It's easier to use a simple script that releases dozens of MB in a few seconds.

> But for 99% of modules, this has no impact at runtime.

Traditionally, this wasn't an acceptable way to think about projects we engineers were being paid lots of money to build.

As you note, a project may hoover in some absurd number of dependent libraries and you have no tooling that tells you which of those might fall in the 1% and what code paths in those 1% intersect with call stacks in your project. You have no idea what impact blindly deleting some "They're probably unnecessary" files in somebody else's code will have on your application and no insight into how to make sure your testing unearths problems. It's an invitation to phantom bugs of unknown scope and the most frustrating kind of debugging effort that comes from chasing those kinds of phantoms.

It's already bad enough that people don't read and review their dependent code with the eye they bring to PR's from their on-team colleagues, but to then go futzing around and deleting things in the unread dependencies because you have a hunch that it's no big deal is about as far from software engineering as you can get.

> Of course, this entails the risk of occasional breakage. But for 99% of modules, this has no impact at runtime.

Right so most projects end up with 100's (random one I have is 700+) modules. Which would mean multiple breakages.

The worst part isn't the breakage - it's not knowing where or when it breaks, and because it could be missed when it's being bundled it can happen in production.

The bundling step should effectively be doing the file pruning for you (or even parts of files) and you can be a lot more confident that won't miss things.

node_modules are generally big (580MB in my case), but I don't know why you'd trade 580MB of storage for reliability. For us the 580MB will get bundled under 1MB for our web application, essentially all dev machines will be 512GB+ at this point anyway.

> But for 99% of modules, this has no impact at runtime.

> Have you seen the number of modules installed by most major libraries?

Chances of success, negligible.

Translation: take 99% to the power of 'a lot' and what do you get?

> but for 99% of modules, this has no impact at runtime

So for the typical enterprise crapware where the app template installs about 2,000 packages for a React Hello World, how many broken modules is that?

Reply on news.ycombinator.com