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

You may not need a bundler for your NPM library

cmdcolin.github.io

Post reply on HN
Print view View original

1–10 of 40 posts

Re: You may not need a bundler for your NPM library

#3

Post by duttonw »

Nice write up. It still boggles the mind when coming from a Java background how things change but also get worse.

Having zip's (.jar/.war) which had the source and compiled artefacts available and not cluttering the OS with unzip items.

I've run into huge issues dealing with deployments to AWS Lambda nodejs, where the previous developer could not work out how to make a 'slip' deployment and just zipped the whole folder node_modules and all and shipped that, this included all testing tools including an entire browser exe etc. 150mb file expanded to 350mb with 300k in files. And 95%+ of it was boiler-pate to test the api endpoint logic...

I've still not come across the simplest way to have dependences on modules with testing and still be able to deploy a slim zip. There is more and more push to do container layers for the node_modules, but still many of these has 100'000 objects which are not needed causing lambda stutter(startup sleepyness).

Re: You may not need a bundler for your NPM library

#5

Post by brundolf »

A lot of libraries are published along with various types of bundles and non-bundles, including usually the source, so the user can pick which one is best for them. For example, you can import just one Lodash module at a time so you don't have to bloat your app with the whole library. This seems like the best of both worlds

We're converging on better norms for JS dialects/module systems, but we're not all the way there yet, so I don't see much purpose dropping support for multiple formats when some people might still need some of them

If you do want to go clean-slate and drop all the ceremony at once, I recommend Deno :)

Re: You may not need a bundler for your NPM library

#8

Post by andreareina »

- bundles let you ship less code (tree shaking)

- dependency versions being fixed is a feature. I've had package installs fail because a dependency published a semver-compatible update that broke something. In a web context this would break the app until the dependency pulled the update or the dependent pushed an update disallowing that version.

Re: You may not need a bundler for your NPM library

#9

Post by quackware »

This might make sense for performing a "final" build or for very small libraries, but IMO not really for anything beyond that or for any sort of application level codebase. Some of the links in OPs post mention projects and not necessarily libraries, where the amount of code included can increase pretty quickly and tsc is just so so so much slower then using a tool like vite/esbuild/tsx/vitest or similar swc derivatives. I think relying on your IDE for type checking and linting while periodically performing a full typecheck via tsc in CI could be the sweet spot. Not to mention other features like hot reloading, auto re-running tests, etc that these bundlers and tools that utilize them expose for you.

At least for me I think maintaining a tight feedback loop between "make a change" => "verify it works" is important to not be distracted by another task. esbuild taking 100 or so ms while tsc taking 30+ seconds makes a world of difference for that.

Re: You may not need a bundler for your NPM library

#10

Post by _ZeD_ »

davidmurdoch wrote: post #4

> If you are bundling dependencies, you are not allowing people to get updates to your sub-dependencies with semver! That's a reason for bundling.

if you want to work with a vendored copy of a dependency, do it clearly; copy the sources in src and remove the dependency from the package.json
Post reply on HN