Exporting as ES Module Syntax (ESM)

[abdonrd]

Please, export "module" entry point in the package.json as ES Module Syntax (ESM).

More info about it here: https://www.pikapkg.com/about/

How to reproduce the issue:

Just download the package or see it at unpkg:
https://unpkg.com/graphql-tag@2.10.0/src/index.js?module.

[abdonrd]

@JoviDeCroock If you have not seen it, I suppose it may be of your interest 🙂

Introducing: @pika/pack
npm package building, reimagined

[abdonrd]

Any news on this? Thanks in advance!

[JoviDeCroock]

I have done a PR, there I got asked to convert this repository to TypeScript first but since no maintainer has been active on the repository.

[abdonrd]

Ouch! 😢

Thanks anyway for your work!

[JoviDeCroock]

Well, on the bright side it is not that you would be able to tree shake anything anyway so using the CJS is functionally equivalent.

[langpavel]

I'm really thinking about rewrite this to typescript + emitting .ts files for better developer experience.
There is no simple tool ATM, so I will try my best to emit input and output types for native typescript, so VSCode and other languageservices can benefit from.. Ask me after week please if you are interested

[JoviDeCroock]

@langpavel already doing this but waiting for merge, you can always help out by making PR's to the /typescript branch.

[langpavel]

@JoviDeCroock I must break for some days, but here is what I do last week:

• loader emits just wrapper to load generated .ts file
• require(...) → require(...).default
• Does NOT emit valid type information (not yet)

https://gist.github.com/langpavel/ffd6ecb5ba655b7b4bff3ebdca0942f0

[JoviDeCroock]

@langpavel Do it on the official repo

[alfaproject]

Is there any hope for this?

[carlocorradini]

Any update? 😥

[jerelmiller]

Hey all 👋

Appreciate the patience on this issue. Unfortunately I can't quite guarantee a resolution on this issue as we are still figuring out our ESM strategy. Any change would require a major version bump to this package, which also has downstream effects on the core @apollo/client library that uses this package. Ideally we'll update both of those packages together to ensure they are compatible with each other. The good news is that ESM support is something we are planning to tackle with @apollo/client v4 which we are currently starting to plan out. I don't quite have a timeline on what that will look like quite yet.

Unfortunately ESM support isn't quite as simple as adding a module or exports property to package.json. Mark Erickson has a great blog post on the challenges related to ESM support, which I encourage you to read if you're interested. Thanks for the patience!

EDIT: Seems I was a bit naive on the state of ESM in this library. See my recent comment.

[JoviDeCroock]

In the meanwhile if you really need ESM, we have had stable ESM support on urql for a few years!

[jerelmiller]

Ok seems I was a bit naive in the state of things, so my previous comment can be ignored.

#325 did the necessary work to ensure this library has proper ESM compatibility. You can see the module property defined in package.json and that its entry file is ESM via unpkg.

Given this is a 5 year old issue, I feel leaving this issue open is misleading on the state of ESM in this library, so I'm going to go ahead and close this as completed via #325. For those that are having ESM issues, I encourage you to open a new issue with a specific problem so that we can look at it further. Thanks!