Typescript module, multiple exports, where do you begin?

Rasmus Schultz - Mar 3 '22 - - Dev Community

I'm building a Typescript library. 🤔

It's going contain several related packages - I want them under a single source-control, but I want them published as packages you can install individually, because some of the packages will have larger dependencies, and I want to keep the main package lightweight.

I'm guessing I need some sort of monorepo setup? I'd prefer to use whatever is available in plain old npm - please, no yarn or third-party monorepo tools.

At least one of the packages is going to have multiple exports in package.json - that is, it will contain multiple modules in the same package. This will make sense for packages that ship with optional modules - keeping them close at hand, but loading them is optional.

The Typescript source module structure won't necessarily match the published modules - that is, I might decide to use more TS modules published as fewer compiled ES modules, just for cleaner structure, so I will probably need some sort of bundler as well.

I've looked at Typescript project references and npm workspaces, and it's not clear to me if I need either or both of those?

I'd like to use esbuild or rollup for bundling - but I need exports in package.json, which does not seem to be an npm standard feature? Is it a node feature? Or is it specific to webpack maybe? I don't understand where this feature "belongs" or comes from?

My library should work both on the web and under node.

Emitting .d.ts files is important, since it's a TS package.

Publishing modern ES modules would be fine - if this requires a recent version of a browser or node, that's fine; supporting older platforms is not a concern for this library.

Supporting Deno is "nice to have" but not a must. I realize I'm already throwing up a long list of requirements here. It's not completely clear to me if publishing for Deno requires you check-in the compiled files - or if it's better to just structure the TS module sources to fit? If so, I'm willing to do that.

Where the heck do I start?

I'm willing to make concessions here, in favor of simplicity. If that means I have to restructure my code, or if publishing individual packages rather than multi-module packages (with exports) makes things easier, then yes.

There's a wealth of articles and documentation, but it's never clear to me which of them apply to my situation. There are so many options and avenues, and every time I sit down to try to figure this out, I get lost and overwhelmed - by the time I have 50 tabs open, I just close everything and give up. 😅

I really just want to keep things as simple as possible - as few tools and as little configuration as necessary.

Help? 😄🙏

. . . . . . . . . . . . . . . . . .