2. A module bundler - the fun begins
1 min read
Previous1. Separate repository and monorepo toolNext3. Module registry (a place where packages get to chill)
Last updated
Was this helpful?
1 min read
Last updated
Was this helpful?
This page is part of list - 2/7
You can make Rollup's config somewhat opinionated easily which means that if you find a setup that works for one package, it's likely to work across the board with minimal fuss.
This consistency is a big win when managing multiple packages, ensuring they're all bundled efficiently in the same manner.
And it doesn’t stop there.
Each package adopts a specific stance, making sure that whether I’m whipping up a new consumer app, a browser extension, or even a desktop application, the development experience remains consistent.
Everything is expected to work, act, and behave the same, regardless of where it’s implemented.
Having established our bundling strategy with Rollup, the next logical step is to consider where our packages will live.
I went with , thanks to my previous experience with it. You can read more about bundlers .
To keep it clear: Rollup itself is not opinionated - just look at this
So, what's the deal with the packages in ?
Each package serves its unique purpose, acting as a piece of the larger puzzle. They're essentially for different areas of functionality:
bundles and related dependencies. Adding it as a dev dependency means you’re indirectly installing TypeScript itself.
includes everything you need for /JavaScript unit testing, like and , along with a few other relevant plugins.
