Package Exports

[jasonkuhrt]

Newer versions of GraphQL Request require TypeScript to be configured such that it will read package.exports. This decision is to help modernize the community, like with some popular library authors over the past few years have switched over to ESM-only packages. It also reduces my burden by preventing unofficial deep imports.

• https://www.typescriptlang.org/docs/handbook/modules/reference.html#node16-nodenext-1
• https://www.typescriptlang.org/docs/handbook/modules/reference.html#bundler

This poll does not mean a democratic decision/change is happening, but I am curious about the results.

If you vote for "...stuck..." please leave a comment about why.

Thanks!

Related:

• Document the requirement of tooling support for package.exports #845

[mrbfrank]

I voted stuck because ESM support in Jest is still experimental. I have not been able to get Jest working with moduleResolution:bundler yet, still working on it. My team is evaluating replacing Apollo with react-query + graphql-request, but the latest ESM-only requirement is causing some friction.

[jasonkuhrt]

Thanks for sharing @mrbfrank. Jest has been an issue for years, been there myself :(

The sense I get is developers are migrating to Playwright, Vitest, or Node's native test runner more and more.

[jonkoops]

Have you tried switching to Vitest for testing? It is largely API compatible with Jest and supports ESM out of the box.

[mrbfrank]

I've also read that Vitest could be a drop-in replacement, but I'm working in a large team with multiple repo's so the motivation to change testing frameworks to adopt a new lib is not there. That's just a reality of working in a large org with multiple teams & we're sticking with Jest & Apollo Client for now. Thanks for your comment.

[demmyhonore]

Just to add: graphql-request is very appealing for React Native apps for being lightweight and minimal. But React Native and Expo are committed to Jest as a framework.

[jasonkuhrt]

This may help users out https://devblogs.microsoft.com/typescript/announcing-typescript-5-5-rc/#respecting-file-extensions-and-packagejson-in-other-module-modes

[mhuggins]

I voted stuck because ESM support in react-native is experimental (via unstable_enablePackageExports), and I couldn't manage to get this package working without downgrading from 7.x to 6.x.

[jonkoops]

It might be worth it to report an issue to the React Native team in that case, especially if you have a reproducible case. Feel free to use graphql-request as an example and link back here.

[mhuggins]

I voted stuck because ESM support in react-native is experimental (via unstable_enablePackageExports), and I couldn't manage to get this package working without downgrading from 7.x to 6.x.

Since I need the latest version of graphql-request, I ended up using patch-package to solve this until React Native is able to support ESM exports. I included the steps below for anyone else who needs to do this. (Note that I'm assuming you're using yarn, feel free to change the steps for npm as needed.)

1. Create a file at node_modules/graphql-request/index.js that contains the following:

   export * from './build/entrypoints/main.js';

2. Run npx patch-package graphql-request to create a patch file named something like graphql-request+7.1.0.patch.
3. Run yarn add patch-package postinstall-postinstall --dev to allow patching as part of the install process.
4. Add an entry to your package.json's scripts property:

   "postinstall": "patch-package"

Now, any time you run yarn install, you should see additional output that shows the patch being applied:

$ patch-package
patch-package 8.0.0
Applying patches...
graphql-request@7.1.0 ✔

[jonkoops]

@mhuggins FYI, if you are using Yarn, it has a built-in mechanism for applying patches. This would eliminate the need to use the patch-package package, and also removes the need to have a postinstall script.

[mhuggins]

@jonkoops TIL, thanks for sharing!

[Velenir]

@mhuggins I have a similar problem but I failed to solve it by only adding index.js. Typescript couldn't recognize graphql-request types no matter what I did with type declarations.

Here's a handmade patch file that worked for patch-package for me. Handmade because patch-package doesn't recognize changes in package.json automatically and can't generate it, but it can apply them alright in postinstall.
patches/graphql-request+7.1.0.patch

diff --git a/node_modules/graphql-request/package.json b/node_modules/graphql-request/package.json
index 83a7126..813e933 100644
--- a/node_modules/graphql-requestpackage.json
+++ b/node_modules/graphql-request/package.json
@@ -4,6 +4,8 @@
   "version": "7.1.0",
   "packageManager": "pnpm@9.4.0",
   "type": "module",
+  "types": "./build/entrypoints/main.d.ts",
+  "main": "./build/entrypoints/main.js",
   "bin": {
     "graffle": "./build/cli/generate.js"
   },

[mallowigi]

We are using NestJS with graphql-request in our projects as well and so far I couldn't find any configuration allowing us to migrate to v7.1.0 with minimal changes.

Ultimately, the configuration that displays the least errors is

"module": "esnext",
"moduleResolution": "bundler",

but open compilation, we are getting this error

(Use `node --trace-warnings ...` to show where the warning was created)
/projects/blabla/dist/src/main.js:1
import { NestFactory } from '@nestjs/core';

Now we don't have any errors in the source code, but the dist directory

[jonkoops]

You might try staring Node.js with --experimental-require-module, this should allow for importing of ES modules from CommonJS. See this blog post for more information.

[mallowigi]

Thanks, I'll give it a try. But I'm a bit worried about these changes, I hope it will not incur issues once running in production or in docker. Thanks for the help

[jonkoops]

Yeah, I really wish the Nest.js team would be a bit more proactive on pushing standardized modules, it and Jest are the primary reasons folks are experiencing issues with ES modules in production.

[mallowigi]

To their defense, considering the sheer amount of users using Nest, migrating to ESM is not a given. If a small package like graphql-request already has a lot of troubles, I can't imagine a monster like Nest do so in the next months. The node ecosystem is really becoming the new Python v2 to v3 clusterf*ck.

[jonkoops]

Yeah, to be very fair it's a compatibility issue that only exists in Node.js, so I can understand their point of view. Other runtimes like Deno and Bun have had pretty decent interoperability for some time now, Node.js is playing catch-up.

[jasonkuhrt]

I am happy to see this change from TypeScript. I believe this will widen the path of possible configurations that users can use to work with modern JS packages in TS.

One thing that I am not sure about at the moment is if this implies that TS will also kick in its exports resolution behaviour –– I think it would/does but not sure.

• https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-beta/
• Only look up package.json type if module is node16/nodenext or file is in node_modules microsoft/TypeScript#58825

[demmyhonore]

Working on an Expo application. Not completely stuck, but quite affected by this decision:

• I need to enable unstable package exports in React Native.
• I need to solve for Jest too (React Native and Expo's default for testing). But breaking out of the jest-expo preset is quite painful, so I cannot enable their experimental ESM. I will try to substitute graphql-request for fetch during testing as a last resort. My other dependencies are: react-query and msw.

[jasonkuhrt]

@demmyhonore I would be curious to hear about your final setup. I am open to having community maintained docs on this topic about what is needed to get these other tools working (despite that it should be these tools taking that work on IMO). It sounds like you have started to track specific steps.

Also, if you conclude it's not worth it, for you, I would be curious what the tipping point is and how close are those tipping points are to finally changing. It will be 2025 soon and I expect Expo and Jest to be coming aground sooner than later now.

Thank you for sharing your experience!

[demmyhonore]

@jasonkuhrt: Sure, happy to share!

So I enabled unstable package exports in React Native.

Then in Jest:

• I mocked the graphql-request's request function.
• Instead of using graphql-request for queries, I switched to using fetch in combination with React Query's useQuery hook.
• In MSW, I had to use HTTP request matching instead of GraphQL request matching.

[mhuggins]

@demmyhonore I'm building an Expo/RN app as well, and I couldn't enable the unstable exports option because of conflicting packages as well. You should check out my solution here.

[jasonkuhrt]

I now have explicit documentation about this part of Graffle: https://graffle.js.org/guides/getting-started#💀-verify-project-configuration.

Any improvements to that content welcome.

Thanks to discussions here I already made a cross link for React Native users.

I continue to be loath to support 1) CJS and 2) main with typeVersions (for multiple entry points) but I still regularly check this discussion and think about the tradeoffs. If before Graffle 8 I see a cheap way to support some legacy setups I'll try to make that happen.

[jasonkuhrt]

Hey, I have a great update. graphql-request and graffle can now be used by CJS projects #1245. There are still some requirements but it's now possible. I am also updating the instructions at https://graffle.js.org/guides/getting-started#💀-verify-project-configuration.

Given this, I am now going to consider this thread closed. It's a great compromise I think.

[jonkoops]

I believe it is also the intention of the Node.js team to backport this functionality to all existing LTS releases, so this might also work for more folks in the future without the need to upgrade a major version.

[jasonkuhrt]

@jonkoops yeah heard that too. We can update the docs as soon as that happens. Seems like a big step forward for the community!