There is also a Spanish version of this post:
Reduciendo Tamaño Paquete NPM en un 83%
Keff ・ Jun 19 '2...
For further actions, you may consider blocking this person and/or reporting abuse
Note that you can also use the
filesproperty in yourpackage.jsonfile to set a list of files that will be packaged along with the mandatory files. The type of this property is an array of strings so it's pretty easy to add packaged files. See this property as a whitelist. More informations on the official documentation.Also get used to the
npm publish --dry-runcommand. It can be useful to see what files are packaged before publishing. It can act as a test for yourfilesproperty. Still in the official documentation.Yup, I read something about the
filesproperty yesterday, I will try this approach, as it might be cleaner!Do you know when should we use
filesand when to use.npmingore?.npmignoreact as a blacklist andfilesact as a whitelist. I guess i'ts a matter of preferences but I would rather be lazy and only define the files that I want to publish, and ignore all the others I didn't mention by using the `files property intsead of blacklisting all others files that should not be published to NPM. Again, a matter of preferences IMO.Ok, thanks! Yup I guess it's a matter of preferences.
I would also rather define what is needed! I may change this then :)
For TypeScript users, files is definitely better than empty .npmignore that found on some tutorials.
Is there a reason to put it under files? In typescript I mean
xD Why would they put an empty .npmignore? I guess just to keep the tutorial simple, and not add more complexity to it... they would be better of just by not having a .npmignore at all
Has an article called "For the love of god, don’t use .npmignore" by Jeff Dickey with awesome content explaining why you could use "files" in package.json instead of .npmignore.
Ohh, thanks, I will check it out :)
I've checked the post out, there are definitely some risks about using .npmignore, like unexpectedly upload credentials or critical information, but the risk is tolerable to the project I was optimizing, I will be taking this into account in the future though!
Switching from Webpack to Rollup also really crushed the individual assets. With proper tree-shaking, externals and attention to side-effects - we saw some of our original code assets go from 100kB down to 10 kB. Maybe that's also possible with webpack, but the config of Rollup is super easy. (We're shipping esm.js with sourcemaps as well as cjs.min.js and d.ts types.)
Cool,
One question though: is it recommended to use such tools, or even to bundle packages for use in pure node-js? Or should it just be done for browser packages?
Well, we’re writing in typescript, so it HAS to be transpiled. Generally speaking, I try to write my modules so that they are isomorphic, which means they will work in both browser and node. The thing though, is that these days you just don’t know what context is going to be used for importing your modules. Some people write in TS, others use vanilla JS in node contexts, and others prefer to make use of ecma2015 features and then transpile themselves. Offering multiple versions allows them to choose the best approach for integration - and using tooling like webpack or rollup with Babel makes it possible for you as a developer to be unopinionated and still write the code how you prefer.
Well, I'll play the usual jerk now. ^_^;
It says
.npmingoreinstead of.npmignore, where? The first time it is mentioned, just below.gitignore, third paragraph.Thanks for the article and the advice about premature optimization
Thanks, fixed! Glad you liked it :)
First of all, it's always a good practice to use extensions like 'Import Cost', that display import/require package size in the code, to notice it right away..
Ohh cool plugin :) I currently use Bundlephobia for this... but it's nice to have it in code!
I added size-limit for this, I run it on every commit and pr, and I will not accept pull requests if they exceed this thresholds for no reason!
Great idea for a post! Reducing the size of your NPM package also helps adoption and performance. 83% is a meaningful reduction for mobile users as well.
Good point, I didn't think about that. Mobile users, and in places were internet is slow it can make a huge impact. I always try and remember that not everybody has gigabit-speed internets and try and apply it to all of the projects I can.
Hey, I just released this post in Spanish, in case anybody is interested in reading it:
Reduciendo Tamaño Paquete NPM en un 83%
Manolo Edge ・ Jun 19 ・ 2 min read