[meta] ship only production files #324
Conversation
this will give you ~90% reduction of your on-disk node_modules footprint (from 644K to 65K). Good work with the test, bud, but don't ship them...
|
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected] |
|
@ljharb Mind that vanilla-js non-bundling users are a great part of the users. P.S: Thanks in advance |
|
Because
|
|
Thanks for your answer - I learnt something new - I'm happy to meet a real person! Would you mind to help me understand the use-case where a package consumer would want to run the packages tests from their production I'll tell you how I got here, LMK what you think. I'm on a personal quest to reduce the size of IMHO there quite a few different reasons. I just started my research, meeting the people and understand them. Anyway, IMHO - Big footprint is not only disk, it's also network. And CPU. Not only on developer local -machines, You see, in the end of the day it's money and CO2. . . . I got to Thanks for your answers, I'll appreciate having your honest opinion. Thanks again. |
|
The use case is one I have all the time - I'm offline, and I want to run the tests on an installed dependency, to determine if it's behaving correctly in my node version.
I think this is not a valuable effort; disk space is effectively infinite and free. Additionally, the party who could most impact this (or CPU, or bandwith) is npm itself, and if they don't care about solving this problem, nobody else is going to be able to make a dent in it.
For browsers, the solution is indeed to just use a bundler. For servers, while bundling often causes faster startup time and is worth exploring,
|
|
Jordan, Thank you for your respectful answer, I was afraid for a moment, but had to do ask. You gain my respect 👍
Well, ths startpoint of the discussion is a
Yes!! I get to do that. I definitely been there, although not as often as you say, and definitely even less when I'm off-line. I found that when using (At least, that's how it used to be before workspaces feature hit the market, maybe my old opinions need updating. 🤔 woups. when I say " like they did in CI" - I am assume the CI tests for all the declared supported node versions. 🤔 I'm still on the pre-release test side, but I'm keeping an open mind...
I agree that The thing is, my personal development roadmap in past years took me through the ops perspective - so I'm seeing things from that perspective as well as developers. I have become aware of the bill, which made me aware of the waste. And since cloud bill is also a proxy for CO2 footprint - that made me ashamed 😞. True, kick-starts would rather throw money at the problem and move fast. But I would love to believe that after this many years of node we'd have better practices to offer... You know what, let me show you the worst case I met in my showcase of the Do we really need this plastic wrap/plastic straw?
Well, I have already made a dent, although it's hard to show with openly available data because I was working mainly with proprietary ecosystems. Thus, I acknowledged that I turned my efforts in the wrong direction. Jordan, clearly, I have a lot to gain from understanding your perspective better. If you'd like to understand my perspective better - here are two IMHO fun reads: Can you think of a better medium we can continue, or you like it just fine here? Osher P.S: - since you're interested in tests, consider that you might have created a set of base-assumptions that let you ship an untested package, instead of actually testing it. Let me explain: #file: ./automation/pack-test.sh
#!/bin/sh
set -e
set -- $(jq -r '.name + " " + .version' package.json)
rm -f $1-$2.tgz tmp
npm pack
$(mkdir -p tmp/node_modules && cd tmp && npm init -y && npm i -y && npm i $1-$2.tgz);With a little more effort it can be done in a cross-platform manner, but I trust you get the spirit ;) Obviously, this can be included it in the JS test suite, duping load from CI machines to developer machines. const { exec } = require('node:child_process');
describe('project package', () => {
it('should result with a working package', (done) {
exec('./automation/pack-test.sh', done);
});
});woups. ah - I work in the assumption that only CI machines can publish... 🤔 which may not be true for kickstart teams... 🤔 🤔 One more thought: Do you believe that |
|
Publishing almost always happens on a local machine; it's not currently practical to publish from CI with 2FA (automation tokens are explicitly one factor). All of my projects, this one included, run tests on the Regarding your linked articles, the first one only applies if you have compiled dependencies; I do not. The second talks about lockfiles, which I very intentionally never use, avoiding the problems mentioned. I'm happy to keep discussing in another medium, especially since most of this is off topic - find me on Slack, IRC, Discord, etc. |
this will give you ~90% reduction of your on-disk node_modules footprint (from 644K to 65K), and your package size from 35K to 9.3K.
Good work with the test, bud, but don't ship them...
Here's your current status:
if you ship only
index.js,libandbin....here's the impact on the package size: