Best output format for a TypeScript library

[grim gale]

Hello, I'm writing a JS library, using TypeScript (because of static typing) and ES6 -style modules.

I'm wondering what is the best format to package my library. My target are all modern browsers and Node.js, I've read ES6 modules are now broadly supported by browsers and Node.js; thus, is it a good choice?

Sadly I've seen that the test framework I'm using (jest) doesn't support ES6 modules. Therefore I think I have to fallback on commonjs. But commonjs can't be used on browsers, so shoud I make two different outputs? 🤔

[robust geode]

are you stuck using jest? it should be pretty easy to swap it out with a different test runner, and only having to publish a single module format would make your life significantly easier

[grim gale]

yes sure, I agree, but I was wondering, how do TS devs usually do? if you e.g. have developed a client for some webservice, which type of module format would you use to make it available on browsers and Node.js?

Node.js ES6 support still seems experimental

so I would still rely on commonjs for Node.js

[robust geode]

it's stable at this point

it all depends on who your target audience is, but if it's users of modern-ish versions of node.js and browsers, then ESM-only seems like a fine choice

i think if i were publishing a general-purpose npm package today i wouldn't bother supporting commonjs until a user specifically asked for it

[grim gale]

If it's stable I can't explain why I have to use this flag to enable them:

NODE_OPTIONS=\"$NODE_OPTIONS --experimental-vm-modules\" npx jest

[grim gale]

Thanks, makes sense 👍

[robust geode]

what version of node are you using?

[grim gale]

v18.13.0

[robust geode]

you can see it's stable here: https://nodejs.org/api/esm.html

Stability: 2 - Stable

[grim gale]

oh, v23 now

[robust geode]

ESM is experimental in Jest, not node: https://jestjs.io/docs/ecmascript-modules

Jest ships with experimental support for ECMAScript Modules (ESM).

i think it's hard for them because they do a lot of runtime magic

if you use a simpler test runner it's not a problem

node has a built-in one these days that's been working well for me: https://nodejs.org/api/test.html

[grim gale]

do you suggest any simpler test runner?

ah okay

[robust geode]

it's also one less dependency to manage, which is nice

[grim gale]

Just found out I have to add .js extension to every import because TypeScript transpiler doesn't add it

and then module resolution fails on browser

very bad...

[robust geode]

yeah TS never touches your import paths. what you write is what you get

what problem are you having in browsers though?

that should work fine as long as your web server is configured to serve the files

[grim gale]

ah, I'm using a static web server (node's http-server) and I think it's not instructed to append .js to files without extension

so import { Class } from './Class' would fail

but import { Class } from './Class.js' would not, so I'm appending .js also in TypeScript code

[robust geode]

right yeah, but here you're saying that adding the .js makes module resolution fail in browsers?

and then module resolution fails on browser

or was that without .js?

[grim gale]

ah no I mean without

[robust geode]

ah gotcha

yeah just use .js everywhere