(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 }