core: (reactivity) Type check fails when '--isolatedModules' flag is provided
Version
3.0.0-beta.14
Reproduction link
https://github.com/sapphi-red/vite-reactivity-isolated-modules-minimal-reproduction
Steps to reproduce
$ npm i$ 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.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 16
- Comments: 24 (8 by maintainers)
Commits related to this issue
- Disabled isolated modules because there is a bug in vue.js currently. https://github.com/vuejs/core/issues/1228 — committed to wrathofrathma/vue-tailwind-template by wrathofrathma 2 years ago
- Disabled isolatedModules & noImplicitAny flags. isolatedModules flag was causing vuejs reactivity compilation errors. See error below and https://github.com/vitejs/vite/issues/5814 & https://github.c... — committed to wrathofrathma/newtab by wrathofrathma 2 years ago
- Fix (hack) tsc compiler complaining about isolatedModules... https://github.com/vitejs/vite/issues/5814 https://github.com/vuejs/core/issues/1228 — committed to amcsi/live-scripts by amcsi 2 years ago
- feat: use enum to replace const enum (#9261) close #1228 — committed to vuejs/core by xiaoxiangmoe 7 months ago
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!
Just chiming in here, please fix this! Especially since this is now default for vite’s vue-ts template: https://github.com/vitejs/vite/pull/7304
@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. whereisolatedModulesis 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).Surely
isolatedModulesis necessary? Whether transpiling TS with esbuild (i.e. Vite) or babel, it is a requirement. Therefore, we want to keep it on when runningtsc --noEmitbecause 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,
isolatedModulesor 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.
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 myd.tsfiles seems like a really great way to make learning more difficult and shoot myself in the foot.Also wondering what the status of this is?