When I implement the pattern for the NormalModuleReplacementPlugin, I expect that the ts-loader would be aware of the configuration and help swallow the compiler error so the compilation would finish.
Because './config/config-APP_TARGET' does not actually exist, the compiler throws an error:
ERROR in ./ClientApp/boot.ts
Module build failed (from ./node_modules/ts-loader/index.js):
Error: Typescript emitted no output for D:\GitHub\NMRP-Plus-TypeScript-Repro\WebPack-NMRP-Repro\ClientApp\boot.ts.
at successLoader (D:\GitHub\NMRP-Plus-TypeScript-Repro\WebPack-NMRP-Repro\node_modules\ts-loader\dist\index.js:41:15)
at Object.loader (D:\GitHub\NMRP-Plus-TypeScript-Repro\WebPack-NMRP-Repro\node_modules\ts-loader\dist\index.js:21:12)
ERROR in D:\GitHub\NMRP-Plus-TypeScript-Repro\WebPack-NMRP-Repro\ClientApp\boot.ts
./ClientApp/boot.ts
[tsl] ERROR in D:\GitHub\NMRP-Plus-TypeScript-Repro\WebPack-NMRP-Repro\ClientApp\boot.ts(1,20)
TS2307: Cannot find module './config/config-APP_TARGET'.
The code executes locally anyway, but because webpack throws a failed error code at this point, automated build systems like Azure Pipelines fail.
You have to add a config-APP_TARGET.ts file to the config folder, with a blank exported module mirroring your actual config module, so that the compiler does not error out.
It would be really nice if this workaround was not necessary.
See repro below.
https://github.com/CloudNimble/NMRP-Plus-TypeScript-Repro
I hope this information helps someone who runs into the same problem, and I hope it can ultimately be fixed so that the pattern in the documentation can be implemented as-is.
Thanks!
Essentially here you're battling the TypeScript compiler. Thanks for sharing the workaround; that's helpful information.
I'm not sure what would make sense in terms of a change to ts-loader to support this more directly. We're open to PRs though... So if you have a good idea do share!
Thanks for the quick response!
Well, does ts-loader have access to the webpack configuration instance? Because if so, then ts-loader could parse the files with the NMRP function and hot-swap the values before the file is actually compiled.
Another option would be for ts-loader to parse exception messages with the NMRP function, and if any of them match, then swallow the exception... because the generated code still functions.
The third option would be for me to open a ticket with the TypeScript team and link to this issue, which I will do in the morning. Really appreciate your help... have a great night!
have a great night!
Ha - it's 7am here :smile:
Well, does ts-loader have access to the webpack configuration instance?
ts-loader has access to everything that any loader has access to. I'm not certain that includes the webpack configuration instance anymore. If memory serves loaders used to have access to that prior to webpack 2. But not since (intentionally). Could be worth double checking that; I'm not 100%.
Another option would be for ts-loader to parse exception messages with the NMRP function, and if any of them match, then swallow the exception... because the generated code still functions.
Probably the easiest option to achieve I'd imagine though it feels hacky.
The third option would be for me to open a ticket with the TypeScript team and link to this issue
I think this is worth investigating..
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.
Closing as stale. Please reopen if you'd like to work on this further.
Hey this seems to still be a problem
I've reopened it - I'm not sure if anyone is looking at it though
Is there any progress on this? i'd really like to replace babel-loader with ts-loader but broken HMR makes me sad
Me too - would you like to work on this? We welcome assistance 馃槉
I would love to assist you however I have no idea about how this stack works.
but before trying to study of how it works i have couple of essential questions
is it possible but nobody has time to work on this?
what was the last problem ?
is it impossible because of tsc behavior?
if second answer is yes - do you have a channel to speak to ts team and request changes?
ok this is more than couple :P
Most helpful comment
I've reopened it - I'm not sure if anyone is looking at it though