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? 😄🙏
Top comments (1)
Have you found any workaround? If yes, Please share it here