You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
When transpileOnly is enabled, ts-loader leaves in re-exports of types, causing webpack 4 to warn about export not being found #751
Reacted by Mike Cluck, Braden Snell, Anton Novik, Spencer Miskoviak, Pedro, jim, Rafael Salguero Iturrios, Artem Trytiak, kareemkibue, Kirill Alexander Khalitov and 3 more
This may very well be a compiler bug, but I'm not sure how to use tsc to reproduce this.
I suspect this is a compiler issue yes. That said there may be good reason for it. I'd suggest asking a question on the Typescript project to confirm if this is expected behaviour or not. ts-loader is doing nothing special here; just hooking into the Typescript compiler API
I think I understand it now. I think it has to do with the fact that transpileOnly uses ts.transpileModule, which is essentially equivalent to turning on isolatedModules. When compiling each module separately, the compiler does not have enough information to know whether an import is a type or not (see microsoft/TypeScript#15231), so while it eliminates imports that are never used in a value position (which works for imported types that are not exported), it cannot know whether an export is a type or not. So, fundamentally, ts.transpileModule is incompatible with type re-exports.
This issue has cropped up now because webpack 4 warns about these invalid exports, but the final bundle otherwise works fine. Perhaps there's an option in webpack to silence these warnings?
Reacted by Ersin Akinci, Michael, Spencer Miskoviak, Himanshu Jariyal, Bnaya Peretz, Mark Salabutin, jim, Alon Mizrahi, Andrei Koperskii, wjunw and 1 more
Thanks for investigating and reporting back - super helpful! It might be worth inquiring against the webpack repo for such an option and linking back to this. I'm not aware of an option myself but that doesn't mean it doesn't exist!
I'm seeing this now in webpack 4.41.2, and the warning looks different, causing the recommended regex to not suppress the warning.
Compiled with warnings.
./src/middleware/sagas/appStartHelper.ts
Attempted import error: 'StartConfig' is not exported from '@instore/middleware/sagas/appStartHelper'
Not sure if this is a result of the version of webpack, typescript, or maybe some munging from create-react-app.
^^ To avoid a DenverCoder9 situation, here's an update.
The example warningsFilter is correct, but if you are working with an ejected create-react-app project, then you need to add this to the build.js script, not to the webpack configuration!
For whatever reason, the warning I posted above is not what you should be basing your regex on. Since the actual warning vs what was being displayed are different strings.
messages = formatWebpackMessages(
stats.toJson({
all: false,
warnings: true,
errors: true,
warningsFilter: [
/export .* was not found in/
]
})
);
This is going to be an issue when using any compiler that has to work without having the full type information... like typescript itself in --isolatedModules mode. As long as there is no syntax to annotate type-only exports / reexports this is going to persist as a problem.
I've reopened this issue following @MLoughry comments on the webpack 5 beta. It seems this issue may present with webpack 5 as maybe an error whereas with webpack 4 it's a warning.
That would be helpful. It's not clear to me that the problems being experienced can be solved by ts-loader. Any "fix" would likely need to be implemented within the TypeScript APIs or handled by webpack configuration.
I'm reopening this ticket for visibility and in the hope that people can use this as a place to discuss the issues. If people could comment that would be amazing.
As it is, ts-loader is a bridge between webpack and TypeScript. It can't (I think) solve the problem of differing needs / aims which this change in approach by webpack represents. But hopefully it can encourage discussion and collaboration between the two 🤗
preserve keeps imports used only for types in the emit as a side-effect import
I think this might resolve the issue reported here so most users just don't bump into it.
We'd look to do this as a breaking changes version if we did.
A little background: as policy we deliberately don't change the default compiler flags often so that ts-loader can generally be treated as a drop in replacement for tsc. But this would seem to be a case which is very webpack specific and consequently appropriate. See:
I don’t think you need to change the default. You can still do export type { T } from './m' to solve the original issue here regardless of the emit setting. We will probably recommend preserve or error for new projects going forward, but I don’t see a strong reason to override the default in ts-loader, unless I’m missing something.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Activity
johnnyreilly commentedon Mar 24, 2018
I suspect this is a compiler issue yes. That said there may be good reason for it. I'd suggest asking a question on the Typescript project to confirm if this is expected behaviour or not. ts-loader is doing nothing special here; just hooking into the Typescript compiler API
univerio commentedon Mar 26, 2018
I think I understand it now. I think it has to do with the fact that
transpileOnlyusests.transpileModule, which is essentially equivalent to turning onisolatedModules. When compiling each module separately, the compiler does not have enough information to know whether an import is a type or not (see microsoft/TypeScript#15231), so while it eliminates imports that are never used in a value position (which works for imported types that are not exported), it cannot know whether an export is a type or not. So, fundamentally,ts.transpileModuleis incompatible with type re-exports.This issue has cropped up now because webpack 4 warns about these invalid exports, but the final bundle otherwise works fine. Perhaps there's an option in webpack to silence these warnings?
johnnyreilly commentedon Mar 26, 2018
Thanks for investigating and reporting back - super helpful! It might be worth inquiring against the webpack repo for such an option and linking back to this. I'm not aware of an option myself but that doesn't mean it doesn't exist!
univerio commentedon Mar 26, 2018
Found the option:
Perhaps we can add it to the readme?
johnnyreilly commentedon Mar 27, 2018
Sure - send a PR!
Add a tip about suppressing "export not found" warnings for transpile…
Add a tip about suppressing "export not found" warnings for transpile…
FourwingsY commentedon Apr 11, 2018
Hi, I met this problem not as warning but as error.
So I cannot suppress it. Anybody has an idea?
univerio commentedon Apr 11, 2018
@FourwingsY Do you have a plugin that converts warnings into errors?
FourwingsY commentedon Apr 11, 2018
@univerio Oh yes i got it. I've set
config.module.strictExportPresence = trueon webpack config. Thanks a lot!enoshixi commentedon Jun 25, 2018
This also works for me and gets the compiler to remove the type export all together:
bjeanes commentedon Mar 6, 2019
That did not work for me, but the solution in babel/babel-loader#603 (comment) did:
bbil commentedon Oct 17, 2019
I'm seeing this now in webpack
4.41.2, and the warning looks different, causing the recommended regex to not suppress the warning.Not sure if this is a result of the version of webpack, typescript, or maybe some munging from create-react-app.
bbil commentedon Oct 17, 2019
^^ To avoid a DenverCoder9 situation, here's an update.
The example
warningsFilteris correct, but if you are working with an ejectedcreate-react-appproject, then you need to add this to thebuild.jsscript, not to the webpack configuration!For whatever reason, the warning I posted above is not what you should be basing your regex on. Since the actual warning vs what was being displayed are different strings.
Jessidhia commentedon Oct 29, 2019
This is going to be an issue when using any compiler that has to work without having the full type information... like typescript itself in
--isolatedModulesmode. As long as there is no syntax to annotate type-only exports / reexports this is going to persist as a problem.johnnyreilly commentedon Oct 31, 2019
I've reopened this issue following @MLoughry comments on the webpack 5 beta. It seems this issue may present with webpack 5 as maybe an error whereas with webpack 4 it's a warning.
See webpack/webpack#9802 (comment)
If people could detail:
That would be helpful. It's not clear to me that the problems being experienced can be solved by ts-loader. Any "fix" would likely need to be implemented within the TypeScript APIs or handled by webpack configuration.
I'm reopening this ticket for visibility and in the hope that people can use this as a place to discuss the issues. If people could comment that would be amazing.
As it is,
ts-loaderis a bridge between webpack and TypeScript. It can't (I think) solve the problem of differing needs / aims which this change in approach by webpack represents. But hopefully it can encourage discussion and collaboration between the two 🤗cc @andrewbranch @sokra
johnnyreilly commentedon Nov 2, 2019
See microsoft/TypeScript#34750 also as suggested by @andrewbranch
Bnaya commentedon Nov 2, 2019
it's possible to re-export types:
eltonchan commentedon Dec 9, 2019
should be set config.module.strictExportPresence = false
johnnyreilly commentedon Jan 4, 2020
With microsoft/TypeScript#35200 (comment) merged I wonder if we should consider changing the default
tsconfigcompiler flag to:--importsNotUsedAsValue "preserve"For webpack 5 given that:
I think this might resolve the issue reported here so most users just don't bump into it.
We'd look to do this as a breaking changes version if we did.
A little background: as policy we deliberately don't change the default compiler flags often so that ts-loader can generally be treated as a drop in replacement for
tsc. But this would seem to be a case which is very webpack specific and consequently appropriate. See:ts-loader/src/compilerSetup.ts
Lines 59 to 63 in 37a0731
I'd be interested in your thoughts @andrewbranch ?
andrewbranch commentedon Jan 5, 2020
I don’t think you need to change the default. You can still do
export type { T } from './m'to solve the original issue here regardless of the emit setting. We will probably recommendpreserveorerrorfor new projects going forward, but I don’t see a strong reason to override the default in ts-loader, unless I’m missing something.johnnyreilly commentedon Jan 6, 2020
Yeah that seems reasonable. I may put some docs in ts-loader to explicitly recommend using one of those too. Happy New Decade by the way! 🥰🤗
stale commentedon Mar 6, 2020
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
stale commentedon Mar 13, 2020
Closing as stale. Please reopen if you'd like to work on this further.