Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve support for ESM #122

Closed
haltcase opened this issue Apr 26, 2020 · 4 comments
Closed

Improve support for ESM #122

haltcase opened this issue Apr 26, 2020 · 4 comments
Milestone

Comments

@haltcase
Copy link
Contributor

haltcase commented Apr 26, 2020

Feature Request

Node 14 is released and will soon become LTS, so ESM is pretty usable out of the box in Node. I'm experimenting with converting my app to use modules (without TypeScript), and the UX for the twitch libraries could be improved.

https://github.com/d-fischer/twitch/blob/9fb614946c95bd14820cfb61f0e353b06bb9fa8b/packages/twitch/src/index.ts#L4

As is, intellisense calls this default import a class (because of the type definitions) but really, to Node, it's the common JS module.exports object.

import TwitchClient from "twitch"

So to make it work in a Node ES module we would have to use its default property to get the class itself:

import twitch from "twitch"
const TwitchClient = twitch.default

Unfortunately the type definitions still don't allow intellisense to pick this up. TypeScript has some interop features for this but standard Node does not. Most of these issues could be sidestepped by avoiding default exports (they're a JS language design mistake in my opinion), and only using named exports.

For backward compatibility a named export could be introduced alongside the current default export, which would at least alleviate these problems today:

export { TwitchClient };
export default TwitchClient;
import twitch from "twitch"
const { TwitchClient } = twitch

This would also apply to the other packages like the chat client, and other exposed default exports.

An ES module build could also be introduced but that's a more involved proposition.

@d-fischer
Copy link
Member

This is currently in the works, there will be a separate ESM build in the package in version 4.1 - keep an eye out, I will publish a prerelease version soon™ 🙂

@d-fischer d-fischer added this to the 4.1 milestone Apr 26, 2020
@d-fischer
Copy link
Member

d-fischer commented May 1, 2020

Currently blocked by lukeed/bundt#3. I forked a lot of other packages, but in this case it's a bit more complicated, since the package I need to modify sits inside a monorepo.

@d-fischer
Copy link
Member

I published 4.1.0-pre.0 anyway, but WebHooks are broken in the CJS version for now.

@d-fischer
Copy link
Member

In the latest prerelease, WebHooks are not broken anymore. I'm closing this issue now that things are working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants