Typescript-compatible exports

[alex-saunders]

I'm trying to import es-module-lexer into a Typescript project but i'm getting the error 'cannot find module es-module-lexer'. I'm fairly certain this becase the package.json main entry points to dist/lexer.cjs which typescript can't resolve due to the .cjs extension. I'm not massively experienced with Typescript so this could well be a problem with my understanding. However, I think it might be best to produce a dist output like:

dist/
├── cjs/
│   └── lexer.js
└── esm/
    └── lexer.js

It would also be great to provide type definitions for the package but I think this is probably a whole other PR!

[guybedford]

Using .cjs is exactly the correct pattern to use for Node.js module support.

Rather, this should be considered a TypeScript issue.

[alex-saunders]

Damn I thought that might be the case. I did some digging before opening this issue and it looks like Typescript are being annoyingly earnest about not accepting 'custom' extensions (microsoft/TypeScript#10939)

It looks like the only way to include this in a typescript project is to vendor es-module-lexer into the project itself..

[guybedford]

This is a bit different to that issue actually, and more just that TypeScript should support a .cjs file in the "main" just like it supports .mjs. .cjs is relatively new so a new issue may be needed here, but it should definitely not have friction to be supported. //cc @weswigham

[alex-saunders]

Interesting! I'll keep a vendored version of es-module-lexer for now and wait and see what progress gets made on the Typescript side.
Cheers for the info @guybedford

[weswigham]

@alex-saunders

I'm trying to import es-module-lexer into a Typescript project but i'm getting the error 'cannot find module es-module-lexer

You probably shouldn't be loading your dependencies JS directly; while there are compiler options to make it work (sometimes), it is slow. If possible, it's usually better to include a declaration file defining the module. Since there's no @types/es-module-lexer package (contributions are welcome), that means including a .d.ts file in your build with a declare module "es-module-lexer" block that describes the shape of the module's exports. Minimally a declare module "es-module-lexer"; will silence the error (and declare the module as any).

This is a bit different to that issue actually, and more just that TypeScript should support a .cjs file in the "main" just like it supports .mjs. .cjs is relatively new so a new issue may be needed here, but it should definitely not have friction to be supported.

While there are some non-default options to make it so you can use js mains for packages without types, we don't really reccomend loading dependencies as JS (it involves way, way more work), and yes, the resolver we use doesn't support the new stuff introduced to handle/alongside native esm yet. We're trying to wait long enough to handle all the new stuff behind one flag, which means waiting for it to stabilize (and even then, there's a lot of resistance to new handling new extensions because of what it implies for declarations; having side-by-side index.cjs.d.ts and index.d.ts is not something we're well-equipped to support (we've never accepted custom cjs extensions), so there's a strong desire to point people toward just "type": "module" (and nested scopes thereof to toggle behavior) and avoid the new extensions entirely - especially since doing so is roughly backwards compatible with old/existing versions of TS, as module format is determined heuristically anyway).

[guybedford]

@weswigham very interesting, thanks for the info here.

[alex-saunders]

Thanks so much for the help @weswigham , I really appreciate the detailed response. I've ended up creating a mostly fleshed-out declaration file and including that in my local build for now but I'll aim to create a @types for package for other people's use ASAP.

Thanks again for filling in the gaps in my Typescript knowledge!