./lib/use/ws' is not defined by "exports"

[meabed]

Error: Package subpath './lib/use/ws' is not defined by "exports" in /node_modules/graphql-ws/package.json

[enisdenjo]

Starting from v6, those paths have changed to omit the /lib/ part. Please read the migration documentation.

- import { useServer } from 'graphql-ws/lib/use/ws';
+ import { useServer } from 'graphql-ws/use/ws';

[meabed]

Thank you @enisdenjo

The type script is giving error still and import is from dist

TS2307: Cannot find module graphql-ws/ use/ ws or its corresponding type declarations.
There are types at
 node_modules/ graphql-ws/ dist/ use/ ws. d. ts
, but this result could not be resolved under your current moduleResolution setting. Consider updating to node16, nodenext, or bundler

[enisdenjo]

Try setting the moduleResolution in your tsconfig.json to a more modern stack - as suggested in the error you attached.

Consider updating to node16, nodenext, or bundler

[meabed]

Thank you @enisdenjo

[meabed]

• only bundler works but it cause lots of other issues :(
• node16 / nodenext doesn't work

The code and import is working if you ignore the ts-error - its just the typechecking doesn't work expect in bundler tsconfig.

Would it be possible to have exports support commonjs as well

[meabed]

I tried so many variations of configs - nothing works correctly.

The only thing working for me now is

const { useServer } = require('graphql-ws/use/ws');

it would be great to have flexibility with other libs and code if possible

[enisdenjo]

It does work with node16 / nodenext, I tried a super simple setup with:

package.json

{
  "type": "module",
  "version": "1.0.0",
  "dependencies": {
    "graphql-ws": "^6.0.0",
    "typescript": "^5.7.3"
  }
}

tsconfig.json

{
  "compilerOptions": {
    "module": "node16",
    "target": "es2022",
    "moduleResolution": "node16"
  },
  "include": ["index.ts"]
}

index.ts

import { useServer } from "graphql-ws/use/ws";

Typechecking yields no errors. ✅

---

However, if changing the project to a commonjs by removing the "type": "module" from the package.json - an error does indeed occur.

Even though graphql-ws has commonjs files:

graphql-ws/package.json

Lines 18 to 57 in 90097bc

	"exports": {
	".": {
	"types": "./dist/index.d.ts",
	"require": "./dist/index.cjs",
	"import": "./dist/index.js",
	"browser": "./dist/client.js"
	},
	"./client": {
	"types": "./dist/client.d.ts",
	"require": "./dist/client.cjs",
	"import": "./dist/client.js",
	"browser": "./dist/client.js"
	},
	"./use/ws": {
	"types": "./dist/use/ws.d.ts",
	"require": "./dist/use/ws.cjs",
	"import": "./dist/use/ws.js"
	},
	"./use/uWebSockets": {
	"types": "./dist/use/uWebSockets.d.ts",
	"require": "./dist/use/uWebSockets.cjs",
	"import": "./dist/use/uWebSockets.js"
	},
	"./use/@fastify/websocket": {
	"types": "./dist/use/@fastify/websocket.d.ts",
	"require": "./dist/use/@fastify/websocket.cjs",
	"import": "./dist/use/@fastify/websocket.js"
	},
	"./use/bun": {
	"types": "./dist/use/bun.d.ts",
	"require": "./dist/use/bun.cjs",
	"import": "./dist/use/bun.js"
	},
	"./use/deno": {
	"types": "./dist/use/deno.d.ts",
	"require": "./dist/use/deno.cjs",
	"import": "./dist/use/deno.js"
	},
	"./package.json": "./package.json"
	},

It seems to be that TypeScript also requires commonjs types to work in commonjs projects.

I'll work on a fix, thanks for reporting!

[enisdenjo]

Fixed in v6.0.1, can you upgrade and try again @meabed? Thanks in advance!

[meabed]

Thank you so much @enisdenjo - it works now with node16.

But it cause lots of other libs to break - if it's not much to ask if it would be possible to support

    "module": "commonjs",
    "moduleResolution": "node",

[enisdenjo]

That configuration is not supported because it is used for very outdated Node, versions older than v12 (v12 official support ended 5 years ago). Supporting that much older version means that the distributed code gets polluted with a lot of polyfils that are simply not necessary in today's stack.

Many libraries, including graphql-ws, release major versions once Node reaches end-of-life and bump the least supported engine to the current LTS.

Current LTS is v20 which is what graphql-ws requires:

graphql-ws/package.json

Line 15 in e1ec851

"node": ">=20"

I still think that something is simply wrong with your TypeScript configuration, because I doubt you're using Node pre v20. If you can provide me with a repro repository that I can look at, I'd be happy to help.

However, if you are using old Node and therefore need TypeScript to generate older code - your only option is downgrading to v5.

[enisdenjo]

node10 (formerly known as node)

--moduleResolution node was renamed to node10 (keeping node as an alias for backward compatibility) in TypeScript 5.0. It reflects the CommonJS module resolution algorithm as it existed in Node.js versions earlier than v12. It should no longer be used.

Even TypeScript itself recommends not using node10 (alias of node) anymore.

[meabed]

Yes totally understandable 😊 I was just highlighting that some stable libraries haven't been updated for longtime and this makes them not usable when switching the configs.

[enisdenjo]

There certainly are workarounds, do you have any specific libraries in mind?

If you don't/can't have a repro repository, you can share the error here and I'll see whether I can help you without context.

[meabed]

Thank you @enisdenjo,

For example: https://www.npmjs.com/package/mathjs

The typechecking import doesn't work with Node16 config here

The only workaround I found is either require('mathjs') or require('graphql-ws')

[meabed]

and the issue here happens with any library that doesn't specifically export everything.

For example:

// this failed in any other tsconfig because this files are not specific in the export.
// Although it's only needed for typing not actually code - so it makes typechecking fail - but the code passes.
import type { DeleteOptions, MetadataResponse } from '@google-cloud/storage/build/src/nodejs-common/service-object';

// so I had to replace them with something like this - which makes typechecking more complex and very hard to understand.
Parameters<File['delete']>;
ReturnType<typeof .....>;

Another lib example https://github.com/kysely-org/kysely

// this type import fails in node16 / nodeNext
import type { DataTypeExpression } from "kysely/dist/cjs/parser/data-type-parser";

there are many other examples :) but i think you got the idea.

If supporting commonjs /node10 export won't break anything - I think it's great to add it in so developer don't suffer more with typescript 🙄

[enisdenjo]

Sorry for the late reply @meabed, I am quite busy. Here's my input on the given libraries:

mathjs

The library does support ESM, but they incorrectly use the package.json#exports field. There's an issue but it seems to be unhandled: josdejong/mathjs#1928.

kysely

import type { DataTypeExpression } from "kysely/dist/cjs/parser/data-type-parser";

Import fails probably because you're direclty importing from cjs. The issue is really that DataTypeExpression is not exported by the library - if you need it, I recommend opening an issue on their side; or use the esm side of things:

- import type { DataTypeExpression } from "kysely/dist/cjs/parser/data-type-parser";
+ import type { DataTypeExpression } from "kysely/dist/esm/parser/data-type-parser";

@google-cloud/storage

Same story as with kysely.

---

Sorry, but all these are oversights of the relevant library maintainers. I don't want to take graphql-ws one step back just to accomodate others' issues.

You can always "patch" those libraries with your package manager and rid of these issues by defining correct package.json#exports.