Repository navigation
isolatedModules - potential issue with @types? #16351
Description
Hello!
I'm one of the maintainers of ts-loader, a TypeScript loader for webpack. We've recently been doing some work to improve performance by switching ts-loader to transpileOnly mode and using the fork-ts-checker-webpack-plugin to perform type checking in a separate process.
As a further optimisation we've been thinking about making use of the isolatedModules flag to make ts-loader do even less work. However when testing this out Oden (@odensc) has stumbled upon this error:
ERROR at /home/oden/Dev/JS/fttv/node_modules/@types/babel-core/index.d.ts(16,19):
TS1205: Cannot re-export a type when the '--isolatedModules' flag is provided.
I wanted to raise this to check if there some kind of issue using isolatedModules in conjunction with Types (@types)?
Also, I wanted to request guidance on use of isolatedModules - there isn't much documentation on the flag that I've been able to find. Will setting the flag to true affect the experience of users in vscode / visual studio / alm-tools etc? Will less errors etc be reported if this flag is set?
I ask as, historically, ts-loader has used the tsconfig.json as is and has done no "magic" with it. However, if by setting isolatedModules to true then we degrade the IDE experience then I can see a reason for deviating from this. i.e. Having ts-loader setting isolatedModules to true internally if a certain ts-loader config option is set. But is this necessary? Does this flag have any bearing on the IDE experience? I simply don't know at present I'm afraid.
cc James Brantly (@jbrantly) Piotr Oleś (@piotr-oles) Oden (@odensc) Basarat Ali Syed (@basarat)
Possible related issue: #2812
Activity
basarat commentedon Jun 8, 2017
isolatedModuleshelps prevent writing code that might break if a file is compiled individually vs. part of a compilation context.Essentially errors pointed out by isolatedModule would block a reliable emit on a file by file basis i.e. using
ts.transpile(individualFile).So by
isolatedModuleyou get more errors. e.g. global namespace usages will become errors.Example:
file afile bBecause we need to emit
log(t.foo)which is something we can only know iffile ais a part of the compilation context.PS: Always a please to hear from you John Reilly (@johnnyreilly) ❤️ 🌹
My dream (might not be valid) would be that isolatedModules has no effect on
.d.tsfiles as they are not re-emitted. But of course I can be wrong ❤️mhegazy commentedon Jun 8, 2017
Andy (Andrewkraft) (@Andy-MS) we should not check this if we are in ambient context, regardless of the compiler options.
johnnyreilly commentedon Jun 8, 2017
Thanks for advising Basarat Ali Syed (@basarat) - as helpful as ever! 💓
So it seems like I have
isolatedModulesbackwards then! It's actually not going to improve performance in ts-loader at all!Following your explanation I'm now curious; do you know of a good use case for
isolatedModules? Short of writing a repl I can't think of one (and I'm totally sure it earns its keep there). But doubtless this is solving a problem?basarat commentedon Jun 8, 2017
True.
If you know you are going to compile your code using
ts.transpileyou can setisolatedModulesto true to warn you about any TS that might generate potentially invalid JS 🌹johnnyreilly commentedon Jun 8, 2017
Cool - thanks 🌷
BTW ts-loader uses
ts.transpileModule- is that any different tots.transpile?basarat commentedon Jun 8, 2017
Its the same.
transpileis just a convenient wrapper aroundtranspileModuleand simply returns theoutputTexthttps://github.com/Microsoft/TypeScript/blob/441d76206578db4069c030b173ae660137532764/src/services/transpile.ts#L118 for when you don't care about diagnostics and sourcemaps 🌹johnnyreilly commentedon Jun 8, 2017
Sweet - you are a fount of knowledge!