2. A module bundler - the fun begins

1 min read

This page is part of list - 2/7

While you technically don't need a module bundler to get your project off the ground (you could just transpile each file from source to output directory and adjust your package.json accordingly), using one can streamline your process significantly.

I went with Rollup, thanks to my previous experience with it. You can read more about bundlers here.

To keep it clear: Rollup itself is not opinionated - just look at this list

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.

So, what's the deal with the packages in exile.watch?

Each package serves its unique purpose, acting as a piece of the larger puzzle. They're essentially boilerplates for different areas of functionality:

@exile-watch/typescript-config bundles TypeScript and related dependencies. Adding it as a dev dependency means you’re indirectly installing TypeScript itself.
@exile-watch/unit-testing-config includes everything you need for React/JavaScript unit testing, like Vitest and @testing-library/react, along with a few other relevant plugins.

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.

Previous1. Separate repository and monorepo tool Next3. Module registry (a place where packages get to chill)

Last updated 9 months ago