8

Typescript module, multiple exports, where do you begin?

 2 years ago
source link: https://dev.to/mindplay/typescript-module-multiple-exports-where-do-you-begin-1on9
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Typescript module, multiple exports, where do you begin?

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? 😄🙏


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK