type: module & moduleResolution: NodeNext fails if the Typescript dependency version is 4.7+

[ClementValot]

Node version: 16.15.0 OS: Windows

Code to reproduce: package.json

{
  "name": "swagger-typescript-api-bug",
  "version": "1.0.0",
  "description": "",
  "type": "module",
  "main": "index.js",
  "scripts": {
    "fetch-types": "swagger-typescript-api -p https://my-website-api.com"
  },
  "license": "ISC",
  "dependencies": {
    "swagger-typescript-api": "^9.3.1"
  }
}

tsconfig.json

{
  "include": ["./src/**/*"],
  "exclude": [],
  "compilerOptions": {
    "esModuleInterop": true,
    "module": "ES6",
    "moduleResolution": "NodeNext",
    "target": "ES6"
  },
   "ts-node": {
      "transpileOnly": true
    }
}

running the fetch-types script raises the following stack:

TypeError: host.fileExists is not a function
    at getPackageJsonInfo (D:\Projects\WebstormProjects\testing-tools\node_modules\typescript\lib\typescript.js:43798:37)
    at Object.getPackageScopeForPath (D:\Projects\WebstormProjects\testing-tools\node_modules\typescript\lib\typescript.js:43765:23)
    at lookupFromPackageJson (D:\Projects\WebstormProjects\testing-tools\node_modules\typescript\lib\typescript.js:116488:28)
    at Object.getImpliedNodeFormatForFile (D:\Projects\WebstormProjects\testing-tools\node_modules\typescript\lib\typescript.js:116482:200)
    at acquireOrUpdateDocument (D:\Projects\WebstormProjects\testing-tools\node_modules\typescript\lib\typescript.js:136051:47)
    at Object.acquireDocumentWithKey (D:\Projects\WebstormProjects\testing-tools\node_modules\typescript\lib\typescript.js:136026:20)
    at getOrCreateSourceFileByPath (D:\Projects\WebstormProjects\testing-tools\node_modules\typescript\lib\typescript.js:165211:41)
    at Object.getOrCreateSourceFile [as getSourceFile] (D:\Projects\WebstormProjects\testing-tools\node_modules\typescript\lib\typescript.js:165158:24) 
    at findSourceFileWorker (D:\Projects\WebstormProjects\testing-tools\node_modules\typescript\lib\typescript.js:118298:29)
    at findSourceFile (D:\Projects\WebstormProjects\testing-tools\node_modules\typescript\lib\typescript.js:118196:26)
error Command failed with exit code 1.

No error is raised if the dependency is Typescript 4.6.2

[js2me]

Hello @ClementValot can you reproduce this problem with using swagger-typescript-api 10.0.1?

[ClementValot]

Same issue with the minimal configuration above. Works with moduleResolution=Node but fails with moduleResolution=NodeNext or Node16

[js2me]

@ClementValot thanks, will work

[cipchk]

@js2me Any progress? Can you solve it first, my test failed:

Failures:
1) Schematic: sta should be working
  Message:
    Error: Swagger schema parse error!
     TypeError: host.fileExists is not a function
  Stack:
    Error: Swagger schema parse error!
     TypeError: host.fileExists is not a function
        at /home/vsts/work/1/s/node_modules/swagger-typescript-api/src/index.js:257:17
  Message:
    Error: Generate error: TypeError: host.fileExists is not a function
  Stack:
    Error: Generate error: TypeError: host.fileExists is not a function
        at /home/vsts/work/1/s/dist/schematics-test/sta/index.js:167:23

61 specs, 1 failure
Finished in 7.686 seconds

[wingkwong]

Also had the same error.

[AlexeyBee]

Any progress?

[nksfrank]

same error

{
  "compilerOptions": {
    "target": "ES2020",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "ES2020",
    "moduleResolution": "Node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "allowSyntheticDefaultImports": true,
    "typeRoots": ["types", "./node_modules/@types"],
    "useUnknownInCatchVariables": true
  }
}

{
  "scripts": {
    "generate-api": "swagger-typescript-api -r --unwrap-response-data --single-http-client --modular --module-name-index=1 -p http://localhost:5000/swagger/v1/swagger.json -o ./packages/queries/src/api"
  },
  "devDependencies": {
    "swagger-typescript-api": "^10.0.1",
    "typescript": "^4.8.2"
  }
}

TypeError: host.fileExists is not a function
    at Object.fileExists (C:\src\Bygghemma.ECP.Web\Clients\node_modules\typescript\lib\typescript.js:167586:63)
    at host.fileExists (C:\src\Bygghemma.ECP.Web\Clients\node_modules\typescript\lib\typescript.js:117448:47)
    at tryFileLookup (C:\src\Bygghemma.ECP.Web\Clients\node_modules\typescript\lib\typescript.js:44293:28)
    at tryFile (C:\src\Bygghemma.ECP.Web\Clients\node_modules\typescript\lib\typescript.js:44285:20)
    at tryExtension (C:\src\Bygghemma.ECP.Web\Clients\node_modules\typescript\lib\typescript.js:44277:24)
    at tryAddingExtensions (C:\src\Bygghemma.ECP.Web\Clients\node_modules\typescript\lib\typescript.js:44255:32)
    at loadModuleFromFile (C:\src\Bygghemma.ECP.Web\Clients\node_modules\typescript\lib\typescript.js:44188:45)
    at nodeLoadModuleByRelativeName (C:\src\Bygghemma.ECP.Web\Clients\node_modules\typescript\lib\typescript.js:44112:36)
    at tryResolve (C:\src\Bygghemma.ECP.Web\Clients\node_modules\typescript\lib\typescript.js:44069:34)
    at C:\src\Bygghemma.ECP.Web\Clients\node_modules\typescript\lib\typescript.js:44032:69
error Command failed with exit code 1.```

[treet]

Same issue, after a lot of testing it seems that swagger-typescript-api simply does not work with typescript 4.8.2 (released 16 hours ago). When locking typescript to 4.7.4 (using e.g. yarn resolutions) it works.

Since swagger-typescript-api requests "typescript: "^4.7.4" it will automatically pick up typescript 4.8.2, so unless you got an existing lockfile that resolves typescript ^4.7.4 to 4.7.4 (the no longer latest version) swagger-typescript-api won't run.

[jiameiw]

same error with typescript^4.7.4 ts-node 10.0.0 have you found the cause yet And when will it be solved，thx a lot

[danielmackay]

Hey guys, I've run into this also. Any ETA?

[vanslly]

If you use yarn you can workaround this issue by using yarn resolutions in your package.json.

swagger-typescript-api@^10.0.1 has a dependency of typescript@^4.7.4 which resolves to [email protected] for me, which causes this error.

Adding a resolution of "typescript": "4.7.4" ensures the breaking version of TypeScript isn't used.

[VitaliKhileuski]

same problem

[ClementValot]

If you use yarn you can workaround this issue by using yarn resolutions in your package.json.

swagger-typescript-api@^10.0.1 has a dependency of typescript@^4.7.4 which resolves to [email protected] for me, which causes this error.

Adding a resolution of "typescript": "4.7.4" ensures the breaking version of TypeScript isn't used.

👍 Or Typescript 4.6.2 if using moduleResolution = Node16 or NodeNext

[fabsenet]

or, if you do not have any idea about fancy package resolutions, you just edit the typescript version, you depend on yourself. that would be line 119 in the screenshot 🤷‍♂️

[tiborgg]

Having the same issue. @vanslly's solution fixes the issue for me. Thanks!

[shreypdev]

I am still having issue after adding resolution, can you tell me exactly what you did @tiborgg please

[shreypdev]

Actually sorry got it working thanks everyone for help

[vanslly]

For those using NPM, which lacks package resolution overrides like yarn, you may "pin" the version of your own typescript dependency as @fabsenet said above.

In my case I could have just changed typescript@^4.1.2 to [email protected], so removing the caret symbol. So by running npm i -D [email protected]. However, the package.json of swagger-typescript-api specifies a minimum compatible version of [email protected], so I do this at my own risk. I could also pin to [email protected] and do an application-wide upgrade.

The next version will pin the TypeScript version to 4.7.X with #401.

[trevorwhealy]

We're having the same problem. Thanks to @treet who explained this very well -

Since swagger-typescript-api requests "typescript: "^4.7.4" it will automatically pick up typescript 4.8.2 (and...) swagger-typescript-api simply does not work with typescript 4.8.2

This means that people interacting with this generator via npx like so:

npx swagger-typescript-api -p http://localhost:3001/swagger-json

Are not going to be able to escape the error by going back to an earlier version of this library

npx [email protected] -p http://localhost:3001/swagger-json

Because, both 9.3.1 and the latest release 10.0.1 pull in typescript 4.8.2 due to the typescript package.json dependency using the minor version bump requirement^4.x in both versions.

So even though it was recently bumped from 4.2.4 to 4.7.4 in the latest 10.0 release, both will still pull in 4.8.2.

It seems that this library swapped to using typescript ^4.x as far back as the 2.0 release

[matsgm]

For those using NPM, which lacks package resolution overrides like yarn, you may "pin" the version of your own typescript dependency as @fabsenet said above.

In my case I could have just changed typescript@^4.1.2 to [email protected], so removing the caret symbol. So by running npm i -D [email protected]. However, the package.json of swagger-typescript-api specifies a minimum compatible version of [email protected], so I do this at my own risk. I could also pin to [email protected] and do an application-wide upgrade.

The next version will pin the TypeScript version to 4.7.X with #401.

This solution, which only overrides swagger-typescript-api, works for me using npm:

  package.json
  
  "overrides": {
    "swagger-typescript-api": {
      "typescript": "4.7.4"
    }
  }

[danielmackay]

For those using NPM, which lacks package resolution overrides like yarn, you may "pin" the version of your own typescript dependency as @fabsenet said above. In my case I could have just changed typescript@^4.1.2 to [email protected], so removing the caret symbol. So by running npm i -D [email protected]. However, the package.json of swagger-typescript-api specifies a minimum compatible version of [email protected], so I do this at my own risk. I could also pin to [email protected] and do an application-wide upgrade. The next version will pin the TypeScript version to 4.7.X with #401.

This solution, which only overrides swagger-typescript-api, works for me using npm:

  package.json
  
  "overrides": {
    "swagger-typescript-api": {
      "typescript": "4.7.4"
    }
  }

This worked for me. Thanks @matsgm!

[juanmait]

For those using NPM, which lacks package resolution overrides like yarn, you may "pin" the version of your own typescript dependency as @fabsenet said above.

In my case I could have just changed typescript@^4.1.2 to [email protected], so removing the caret symbol. So by running npm i -D [email protected]. However, the package.json of swagger-typescript-api specifies a minimum compatible version of [email protected], so I do this at my own risk. I could also pin to [email protected] and do an application-wide upgrade.

The next version will pin the TypeScript version to 4.7.X with #401.

Worked for me although I'm using pnpm and I had to delete and regenerate the pnpm-lock.yaml file for some reason.

[progdesigner]

src/formatFileContent.js

class LanguageServiceHost { ... fileExists(file) { return ts.sys.fileExists(file); } ...

Thank you for adding the above.

[csi-lk]

I couldn't get the resolution stuff to work in yarn berry, so used @jnig's PR linked above until merged

"swagger-typescript-api": "github:jnig/swagger-typescript-api.git#8fba36a790fae21ef073154dab2c9da79908de17",

[XantreDev]

Helps with yarn

"resolutions": {
	"swagger-typescript-api/**/typescript": "4.7.4"
}

[Jungzl]

For anyone who are using pnpm

  "pnpm": {
    "overrides": {
      "swagger-typescript-api>typescript": "4.7.4"
    }
  }

[Misinin]

how correct use "overrides" for npm? I added this in my package.json but it's not work(

[vanslly]

how correct use "overrides" for npm? I added this in my package.json but it's not work(

@Misinin make sure to be using [email protected] or higher: https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides

{
  "overrides": {
    "swagger-typescript-api": {
      "typescript": "4.7.4"
    }
  }
}

[Misinin]

@vanslly Thank you so much that helped me!

[emlyn-arkahna]

Anyone else still seeing an issue after updating to 10.0.3 or should I raise a new bug?