(reactivity) Type check fails when '--isolatedModules' flag is provided

[sapphi-red]

Version

3.0.0-beta.14

Reproduction link

https://github.com/sapphi-red/vite-reactivity-isolated-modules-minimal-reproduction

Steps to reproduce

1. $ npm i
2. $ npm run check

What is expected?

no error with Cannot access ambient const enums when the '--isolatedModules' flag is provided.

What is actually happening?

error was found as below

node_modules/@vue/runtime-core/dist/runtime-core.d.ts:950:10 - error TS2748: Cannot access ambient const enums when the '--isolatedModules' flag is provided.

950 export { TrackOpTypes }
             ~~~~~~~~~~~~

node_modules/@vue/runtime-core/dist/runtime-core.d.ts:976:10 - error TS2748: Cannot access ambient const enums when the '--isolatedModules' flag is provided.

976 export { TriggerOpTypes }
             ~~~~~~~~~~~~~~

---

Note that because esbuild only performs transpilation without type information, it doesn't support certain features like const enum and implicit type-only imports. You must set "isolatedModules": true in your tsconfig.json under compilerOptions so that TS will warn you against the features that do not work with isolated transpilation.

https://github.com/vitejs/vite#typescript

I turned on isolatedModules because vite recommends it.

[underfin]

You can remove isolatedModules option (look like this is necessary ) and add typescript@3.8.3(keep the same version with vue-core).

[sapphi-red]

The same error was found after changing typescript to v3.8.3.
Also I am not in trouble with this error.
I thought it would be better if these error were not shown even if isolatedModules were turned on.
Maybe its more like a feature request than a bug report.

[underfin]

You can remove isolatedModules option (look like this is necessary ) and add typescript@3.8.3(keep the same version with vue-core).

I'm Sorry for typed error with necessary. It should be isolatedModules is unnecessary.

[spikyjt]

Surely isolatedModules is necessary? Whether transpiling TS with esbuild (i.e. Vite) or babel, it is a requirement. Therefore, we want to keep it on when running tsc --noEmit because we are supposed to be checking types, but compiling in the same manner as we would when building the app.

This error is happening because const enums are emitted in the definition files provided by Vue. That doesn't make sense to me - surely const enums are not valid in definition files? They have no runtime equivalent so can't be ambient in any context, isolatedModules or not.

I'd consider this a bug, not an enhancement. It would be a blocker for me using Vue 3 in production because I can't consider deploying without type checking.

[sapphi-red]

FYI setting skipLibCheck to true will make the error not happening. (Of course we will not be able to catch library type definition errors.)

[spikyjt]

@sapphi-red thanks, that does work. However, either this is now a docs bug (should mention skipLibCheck) or still a code bug. I can't see how a library that's primary intended use is with transpiling by either babel or esbuild (i.e. where isolatedModules is a requirement) can be exporting const enums. It makes no sense. Either they should be runtime enums (in which case they shouldn't be in definition files because they are not ambient) or they shouldn't be exported (because they are internal to the library, intended for use at its build time, not the consumer's).

[spikyjt]

For completeness, it's worth pointing out that skipLibCheck will skip checking any declaration files in your own project, which may not be what you want, e.g. if you have the habit of declaring purely ambient entities (e.g. types, interfaces) in .d.ts files. There's no need to do this in a project that is built to optimised output, but in the standard use of tsc it might be preferred to avoid producing empty files in the output.

[privatenumber]

Experiencing this in my project too. In my use-case, I'm trying to reference the NodeTypes enum from @vue/compiler-core to do template node type checks at run-time.

Curious what the expected solution would be on Vue's end to provide a run-time solution?

I found a similar problem in chalk, and the fix was to convert the enum to a union... but seems only sufficient for build-time type-checking.

Edit:
To work around this, I ended up publishing a tool that exports runtime utility methods: vue-ast-utils

[mgdodge]

Unfortunately, this is still an issue. The output from my recent conversion from vue-cli to vite:

node_modules/@vue/runtime-core/dist/runtime-core.d.ts:1028:6 - error TS2748: Cannot access ambient const enums when the '--isolatedModules' flag is provided.

1028     [BooleanFlags.shouldCast]?: boolean;
          ~~~~~~~~~~~~

node_modules/@vue/runtime-core/dist/runtime-core.d.ts:1029:6 - error TS2748: Cannot access ambient const enums when the '--isolatedModules' flag is provided.

1029     [BooleanFlags.shouldCastTrue]?: boolean;
          ~~~~~~~~~~~~

node_modules/@vue/runtime-core/dist/runtime-core.d.ts:1503:10 - error TS2748: Cannot access ambient const enums when the '--isolatedModules' flag is provided.

1503 export { TrackOpTypes }
              ~~~~~~~~~~~~

node_modules/@vue/runtime-core/dist/runtime-core.d.ts:1531:10 - error TS2748: Cannot access ambient const enums when the '--isolatedModules' flag is provided.

1531 export { TriggerOpTypes }
              ~~~~~~~~~~~~~~

node_modules/vue-meta/dist/vue-meta.d.ts:9:22 - error TS6053: File '/home/.../node_modules/vue-meta/dist/ssr.d.ts' not found.

9 /// <reference path="ssr.d.ts" />

Using vue 3.1.1 and vite 2.3.7 - this is going to block me from using vite. The site is migrating from vue-cli to vite, so I can still build/deploy, but I was really hoping for the full vite experience.

[mgdodge]

As a less-than-ideal workaround, I just copied the file from node_modules/@vue/runtime-core/dist/runtime-core.d.ts into a src/types directory in my project, and commented out the lines where the const enums were (currently lines 1112-1113, 1593, and 1621). I then put the following into my tsconfig.json paths configuration:

...
"paths": {
    "@vue/runtime-core": [
        "src/types/runtime-core.d.ts"
    ]
},
...

Because in vite, all I am using tsc for is type checking, this should not affect the build at all. And since the const enums shouldn't be in the type declaration files to begin with, I'm fairly certain this will not even break the type checking that I am hoping to accomplish.

Downside is that, until this is properly resolved, I will need to keep this file up to date manually. However, in my particular case, I think the gains in dev experience might be worth the occasional need to diff this file...for now...especially since there are literally only 4 lines in question.

[mgdodge]

Any word on a fix for this? Using vite 2.7.10, vue 3.2.6, and this still comes up if I don't manually override. Offending lines in the generated typescript defs are now 1215-1216, 1405, 1758 and 1787. Those are the following:

// 1215-1216: The "declare type" line itself is fine, the issue is just the references to BooleanFlags
declare type NormalizedProp = null | (PropOptions & {
    [BooleanFlags.shouldCast]?: boolean;
    [BooleanFlags.shouldCastTrue]?: boolean;
});

// 1415: The export is a const enum
export { ReactiveFlags }

// 1758: The export is a const enum
export { TrackOpTypes }

// 1787: The export is a const enum
export { TriggerOpTypes }

[amcsi]

I'm also getting this issue on a fresh Vite app. What am I expected to do?

[Hextar]

Also encountering that rn while running npm run build.

only way to temporally fix it is to disabled isolatedModules from tsconfig.json

NB: that's ofc not an ideal solution

[Wenish]

Also encountering that rn while running npm run build.

only way to temporally fix it is to disabled isolatedModules from tsconfig.json

well setting isolatedModules to false works for me.
but is this really wanted?

[privatenumber]

Vite uses esbuild, which is why they recommend isolatedModules:
https://esbuild.github.io/content-types/#isolated-modules

Files are compiled independently

Even when transpiling a single module, the TypeScript compiler actually still parses imported files so it can tell whether an imported name is a type or a value. However, tools like esbuild and Babel (and the TypeScript compiler's transpileModule API) compile each file in isolation so they can't tell if an imported name is a type or a value.

Because of this, you should enable the isolatedModules TypeScript configuration option if you use TypeScript with esbuild. This option prevents you from using features which could cause mis-compilation in environments like esbuild where each file is compiled independently without tracing type references across files. For example, it prevents you from re-exporting types from another module using export {T} from './types' (you need to use export type {T} from './types' instead).

[mgdodge]

I think it's pretty clear from the original bug description, and numerous comments following, that the masses wish to follow the official recommendation to use isolatedModules, but the types created by Vue are "dirty" - they contain output such as ambient const enums that are not compatible with this recommendation. The various suggestions to disable this type of checking are (for me and others) non-starters.

My prior comments started out by indicating devs could comment out the offending lines in a copy of the type definitions (since the offending lines are often vue internals anyway) - I have since started using patch-package to accomplish this in a much cleaner, maintainable way. It's not ideal to keep around a patch for type definitions that really should be fixed, but it's better than making a copy that quickly gets out of date, and enables me to keep the safety net that typescript provides.

Please fix the type definitions so devs can follow the vite docs!

[sua-dawn]

Just chiming in here, please fix this! Especially since this is now default for vite's vue-ts template: vitejs/vite#7304

[then3rdman]

Also wondering what the status of this is?

[AaronBeaudoin]

I'd like to chime in here that as a fairly new user to TypeScript, this "skipLibCheck": true "solution" feels like it puts me in a really bad spot. I'm still learning how to work with all the nuances of TypeScript, and just shutting off type checking for my d.ts files seems like a really great way to make learning more difficult and shoot myself in the foot.

[matthew-dean]

Wow, this is a really serious Vue bug that prevents adoption into a modern JS workflow that uses SWC or ESBuild (or a tool that uses those, like Next.js or Vite).

[AnnaMadsenKnowit]

These enums also result in an issue with the verbatimModuleSyntax compiler option.
Error message with yarn build:

node_modules/@vue/reactivity/dist/reactivity.d.ts:295:15 - error TS2748: Cannot access ambient const enums when 'verbatimModuleSyntax' is enabled.

295     readonly [ReactiveFlags.IS_READONLY]: boolean;
                  ~~~~~~~~~~~~~

node_modules/@vue/runtime-core/dist/runtime-core.d.ts:419:6 - error TS2748: Cannot access ambient const enums when 'verbatimModuleSyntax' is enabled.

419     [BooleanFlags.shouldCast]?: boolean;
         ~~~~~~~~~~~~

node_modules/@vue/runtime-core/dist/runtime-core.d.ts:420:6 - error TS2748: Cannot access ambient const enums when 'verbatimModuleSyntax' is enabled.

420     [BooleanFlags.shouldCastTrue]?: boolean;
         ~~~~~~~~~~~~

Vue version 3.3.4
TypeScript version 5.1.6

[yangmingshan]

Just share my problem here.

I'm trying to migrate Vue Mini to Vitest from Jest, just like Vue did. But const enum blocked me, because esbuild can't resolve const enum from @vue/reactivity.

I opened a feature request in esbuild: evanw/esbuild#3359, if esbuild do provide this feature, my problem will be solved.

If Vue find a way to remove const enum, my problem will also be solved.

[yyx990803]

closed via #9261

[AnnaMadsenKnowit]

closed via #9261

Great, thanks Evan