Ts-loader: NormalModuleReplacementPlugin doesn't play nice with ts-loader

Created on 22 Sep 2018  路  10Comments  路  Source: TypeStrong/ts-loader

Expected Behaviour

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.

Actual Behaviour

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.

Workaround:

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.

Steps to Reproduce the Problem

See repro below.

Location of a Minimal Repository that Demonstrates the Issue.

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!

pinned

Most helpful comment

I've reopened it - I'm not sure if anyone is looking at it though

All 10 comments

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

Was this page helpful?
0 / 5 - 0 ratings