Error TS2351 "This expression is not constructable" for new SchemaBuilder

[Nikxt]

We had to update our tsconfig file and this resulted in a new typescript error when creating a new SchemaBuilder.

Code:

export const builder = new SchemaBuilder<{}>(builderOptions);

Error:

error TS2351: This expression is not constructable.
Type 'typeof import("C:/Users/[...]/node_modules/@pothos/core/dts/index")' has no construct signatures.

Changes in our tsconfig:

• Changed "module": "commonjs" to "module": "NodeNext"
• Added line "moduleResolution": "NodeNext"

Full tsconfig.json:

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "NodeNext",

    "allowJs": true,
    "declaration": false,
    "outDir": "built",
    "maxNodeModuleJsDepth": 10,
    "strict": true,

    "moduleResolution": "NodeNext",

    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules"]
}

Package versions:

"@pothos/core": "^3.20.0"
"typescript": "^4.8.2"

Repository with error reproduction:
Repository: builder-ts-error-reproduction

[hayes]

Thanks for the report and reproduction!

I spent some time looking at this today, and I am very unclear on how this is supposed to work for packages supporting both esm and cjs.

Adding "type": "module" to package.json in pothos lets ts load the types correctly, but would completely break cjs support in pothos.

It also looks like if I duplicate type declaration into the esm directory and remove "types" "exports.types" from package.json things would also work.

This is a potential path forward, but would require 3 copies of the type definitions to be shipped. I kinda suspect this might be a bug in typescript where they are not properly account for the combination of "nodeNext" with packages that define "exports" for both cjs and esm.

I won't have much time until late next week to dig into this more. If you have ideas on a path forward I am happy to help implement, but I don't really have a good enough understanding of how all the different config options interact to know how to proceed at the moment.

[MikaStark]

After playing around with the error repoduction repo I succeed to make it works by changing this files :

src/index.mts

import { default as SchemaBuilder } from '@pothos/core'; // was import SchemaBuilder from "@pothos/core";

const builderOptions = {
  plugins: [],
};

export const builder = new SchemaBuilder<{}>(builderOptions);

tsconfig.json

{
  "compilerOptions": {
    "sourceMap": true,
    "outDir": "dist",
    "rootDir": "src",
    "target": "es2021",
    "module": "node16",
    "strict": true,
    "lib": ["es2021"],
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "exclude": ["dist"]
}

BUT it only works up to Typescript version 4.8.2 ! If you install version 4.8.3 you will get

src/index.mts:7:28 - error TS2351: This expression is not constructable.
  Type 'typeof import("C:/Users/mboidin/Documents/Playgrounds/builder-ts-error-reproduction/node_modules/@pothos/core/dts/index")' has no construct signatures.

7 export const builder = new SchemaBuilder<{}>(builderOptions);

[emmanuelbuah]

Run into the same issue as well. Thanks for sharing.

[hayes]

relevant typescript issue: microsoft/TypeScript#50762

Did some debugging, and it looks like the issue is that in nodeNext mode pothos at its root is a "cjs" package, and the "dts" files inside are treated as cjs in compatability mode. This makes ts think that the default export is an object with a "default" property, rather than being the builder class itself.

[hayes]

Just published a new version of all Pothos packages that I'm hoping will fix this. Let me know if that works for you

[MikaStark]

Issue fixed for me but still uncompatible with typescript above version 4.8.2

[hayes]

pushed another update earlier today. Ended up duplicating the all the .d.ts files into the esm directory. Not an optimal solution, but it should work across all versions (and hopefully all ts options) now

[MikaStark]

Hum, now it's not working anymore :/

TSError: ⨯ Unable to compile TypeScript:
src/builder.mts:1:27 - error TS7016: Could not find a declaration file for module '@pothos/core'. 'C:/Users/mboidin/Documents/Projets/woozgo-backoffice-server/node_modules/@pothos/core/esm/index.js' implicitly has an 'any' type.
Try npm i --save-dev @types/pothos__core if it exists or add a new declaration (.d.ts) file containing declare module '@pothos/core';

1 import SchemaBuilder from '@pothos/core'

[hayes]

looks like the build job is copying files differently in CI than on my machine. Must be a linux vs osx difference in how cp works. I think this should be easy to fix, one minute

[hayes]

cp -r dts/ esm/ on osx works likecp -r dts/* esm/ vs working like cp -r dts esm/. New build/release is running now

[hayes]

okay, new version actually has the definition files in the expected locations

[MikaStark]

Still not working :/

[hayes]

something still seems broken though .

[MikaStark]

Good old import { default as SchemaBuilder } from '@pothos/core' is working but for unknown reason SchemaBuilder.plugins is typed never[] | undefined

[hayes]

the esm/package.json that marks the esm directory as being "type": "module" got deleted for pothos/core... pushing a fix

[hayes]

okay, I think it's fixed for real this time. d.ts files are in the right place, the pasckage.json file for the esm directory is restored, the repro from above now works on both 4.8.2 and 4.8.4 (for me at least). Let me know if you are still running into issues after this

[MikaStark]

Sorry but, now when implementing SchemaBuilder, the instance is marked as any :/

[hayes]

I've tried a bunch of different combinations of options using the repro repo from above and can't reproduce that, any more info on how to reproduce the any issue?

[MikaStark]

gql-pothos-issue.zip

Here is a little sample of my own project

[hayes]

thanks, I think I see what's going in. Looks like some imports int the esm definintions are not working correctly because they are importing directories rather than explicitly asking for dir/index.js

[hayes]

Sorry this has had so many broken versions. I am hoping it's actually right this time. Needed to transform all the imports to include the full file path. Mind testing one more time?

[MikaStark]

No problemo ;) I love this lib so I'm glad to help.
Seems to be solved this time ;) Well done