adding typescript 5 option "verbatimModuleSyntax": true in tsconfig causes crash

Bug Report

🔎 Search Terms

verbatimModuleSyntax

🕗 Version & Regression Information

This is a crash using the new verbatimModuleSyntax option in typescript version 5.0.2

⏯ Playground Link

This doesn't seem code related, it seems related to the compiler options

💻 Code

tsconfig.json

{
    "extends": "@tsconfig/node18-strictest-esm/tsconfig.json",
    "compilerOptions": {
        "outDir": "dist",
        "module": "node16",
        "moduleResolution": "node16",
        "moduleDetection": "force",
        "allowSyntheticDefaultImports": true,
        "resolveJsonModule": false,
        "declaration": true,
        "pretty": true,
        "newLine": "lf",
        "removeComments": true,
        "noEmitOnError": true,
        "useDefineForClassFields": true,
        "noImplicitThis": true,
        "noImplicitAny": true,
        "strictNullChecks": true,
        "exactOptionalPropertyTypes": false,
        "verbatimModuleSyntax": true,
        "ignoreDeprecations": "5.0" // TODO: when node18-strictest-esm is updated for typescript 5 remove this
    },
    "include": ["src"],
    "exclude": ["node_modules", "dist"]
}

🙁 Actual behavior

> tsc

/Projects/mysql-query/node_modules/typescript/lib/tsc.js:113959
      throw e;
      ^

Error: Debug Failure. False expression.
    at isReferencedAliasDeclaration (/Projects/mysql-query/node_modules/typescript/lib/tsc.js:80348:11)
    at canConvertImportDeclarationToTypeOnly (/Projects/mysql-query/node_modules/typescript/lib/tsc.js:78887:175)
    at checkImportsForTypeOnlyConversion (Projects/mysql-query/node_modules/typescript/lib/tsc.js:78902:11)
    at checkSourceFileWorker (/Projects/mysql-query/node_modules/typescript/lib/tsc.js:79465:9)
    at checkSourceFile (//Projects/mysql-query/node_modules/typescript/lib/tsc.js:79413:5)
    at checkSourceFileWithEagerDiagnostics (/Projects/mysql-query/node_modules/typescript/lib/tsc.js:79507:5)
    at getDiagnosticsWorker (/Projects/mysql-query/node_modules/typescript/lib/tsc.js:79515:7)
    at Object.getDiagnostics (/ /Projects/mysql-query/node_modules/typescript/lib/tsc.js:79492:14)
    at / /Projects/mysql-query/node_modules/typescript/lib/tsc.js:113984:76
    at runWithCancellationToken (/Projects/mysql-query/node_modules/typescript/lib/tsc.js:113954:14)

Node.js v18.15.0`

Note that if I set "verbatimModuleSyntax": false it doesn't crash. The build runs.

🙂 Expected behavior

A clean build or an error message about what is incompatible with setting "verbatimModuleSyntax": true.

feat: add config for TypeScript 5.0

Mike Lippert (@mlippert)

Mike Lippert (@mlippert) In you case it crashes because of this line:

{
      "importsNotUsedAsValues": "error"
}

(I guess) since this prop doesn't exist anymore, which triggers a Debug Failure. False expression..

I just discovered that with another setup. But I agree that errors regarding new options should be explicitly handled with a clean message describing what's wrong when it's easily detectable.

Thanks for tracking that down. Is there any way I can still extend from @tsconfig/node18-strictest-esm/tsconfig.json which is where that is set and start using the new verbatimModuleSyntax option?

I had thought that setting ignoreDeprecations would do it, but I can see why it wouldn't. I just am not sure if there's a way to override that option into undefined.

This is just because I'd like my code to use the latest best practice as soon as I can make it work. If it has to wait for that base config to be updated, it has to wait, but I thought I'd ask.

The importsNotUsedAsValues does still exist. It has just been deprecated and will be removed in Typescript 5.5 (source: https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#breaking-changes-and-deprecations ). This is definitely a bug.

I am getting this error as well, and coming from the @tsconfig/node18-strictest-esm config. I haven't turned on the ignoreDeprecations flag because I can live just fine with that warning for now (and even find it useful as a reminder that it's a TODO thing)

Mike Lippert (@mlippert)

Mike Lippert (@mlippert) As far as I know (but I may not know all the hidden options), it's not possible to ignore/undefine a config prop (I have never tried null which is valid in JSON though).

João Saraiva (@jsaraiva) That's indeed a good point, it's not a removal but still a deprecation as of <v5.5. Hopefully they'll quickly fix that because I think that's a relatively easy fix.

I just am not sure if there's a way to override that option into undefined.

It seems that setting importsNotUsedAsValues to remove works.

It seems that setting importsNotUsedAsValues to remove works.

Won't that cause other issues by removing necessary imports?

Also, I see this has been closed and a PR merged to address the issue but using the latest (5.0.4 at the time of writing) Typescript version, I'm still seeing the same problem.

I'm using Astro, which has the following tsconfig:

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "extends": "./base.json",
  "compilerOptions": {
    "strict": true,
    // Error when a value import is only used as a type.
    "importsNotUsedAsValues": "error"
  }
}

Which I then extend with this:

{
  "extends": "astro/tsconfigs/strict",
  "compilerOptions": {  
    "verbatimModuleSyntax": true,
    ...
  }
}

Is there something else I should be doing?
I tried setting importsNotUsedAsValues to remove, as suggested in the previous comment, and it does seem to get rid of the error message but I'm not sure that's the best solution.

It seems that setting importsNotUsedAsValues to remove works.

Won't that cause other issues by removing necessary imports?

Also, I see this has been closed and a PR merged to address the issue but using the latest (5.0.4 at the time of writing) Typescript version, I'm still seeing the same problem.

I'm using Astro, which has the following tsconfig:
{
  "$schema": "https://json.schemastore.org/tsconfig",
  "extends": "./base.json",
  "compilerOptions": {
    "strict": true,
    // Error when a value import is only used as a type.
    "importsNotUsedAsValues": "error"
  }
}
Which I then extend with this:
{
  "extends": "astro/tsconfigs/strict",
  "compilerOptions": {  
    "verbatimModuleSyntax": true,
    ...
  }
}
Is there something else I should be doing? I tried setting importsNotUsedAsValues to remove, as suggested in the previous comment, and it does seem to get rid of the error message but I'm not sure that's the best solution.

I am facing the same issue.

See the docs on what the old values for importsNotUsedAsValues did. In particular:

remove: The default behavior of dropping import statements which only reference types.

So setting remove should be a noop for your existing code that works with error. What you will lose (I think) is getting errors when, in new/modified code, you forget to add the type modifier when importing types identifiers.

(at least that's how I read the docs, if I got that wrong someone please correct me!)

And here are the docs for verbatimModuleSyntax.

Mike Lippert (@mlippert)

Mike Lippert (@mlippert), yeah, I had already seen the docs, which is why I raised the question of whether the remove option was the right approach. I guess it will do for now.

What we discovered together with a colleague is that if you update to latest version of Vue Plugin (1.6.5) and Vue Language Features (1.6.5) fixes the problem.
For some reason, when I installed the extensions in vscode the version selected was 1.2.

Navigation Menu

Repository navigation

adding typescript 5 option "verbatimModuleSyntax": true in tsconfig causes crash #53302

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

adding typescript 5 option "verbatimModuleSyntax": true in tsconfig causes crash #53302

Description

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

Activity

ivangabriele commented on Mar 20, 2023

mlippert commented on Mar 20, 2023

jsaraiva commented on Mar 20, 2023

ivangabriele commented on Mar 20, 2023

ouuan commented on Mar 21, 2023

borfast commented on May 22, 2023

SimonWoidig commented on May 22, 2023

mlippert commented on May 22, 2023

borfast commented on May 22, 2023

VictorChirita commented on Jun 5, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions