Hi ts-loaders,

Got a new issue for you - happy to provide any additional information you guys need (and also to help out adding the fix if given a bit of guidance).

Versions

• [email protected]
• [email protected]
• [email protected]

Some background:

This is proprietary code so apologies for being slightly vague - I'll work on adding a little repro project if this isn't enough info.

We're using effectively an interface module - just typings - shipped from our local npm server. For production this gets bundled with a real implementation. For local testing however we use webpack to alias a simple local implementation of the interface that we can instrument as we see fit. This local implementation is (important in the context of this bug) written in typescript and needs to be compiled with the rest of the library for testing.

Problem:

The local implementation file is not being compiled resulting in webpack failing to find a valid implementation. Example output:

WARNING in ./test/MockAPI.ts
Module build failed: Error: Typescript emitted no output for D:\dev\project\test\MockAPI.ts.
    at successLoader (D:\dev\project\node_modules\ts-loader\dist\index.js:47:15)
    at Object.loader (D:\dev\project\node_modules\ts-loader\dist\index.js:29:12)
 @ ./test \.tsx?$

Investigation:

I'm pretty sure was introduced by pull #590 in response to issue #586. This logic, which appears to have been added to support typings bundled with js files, is also hit when you have a local .ts file that still needs to be compiled. In our case the new regex matches the typings interface in node_modules, meaning the local implementation is marked as being an "externalLibraryImport" and therefore is not compiled.

The code in question:

Possible fix

A simple fix would be just adding a further check to ensure it's already JS:

if (resolutionResult.resolvedFileName === tsResolutionResult.resolvedFileName ||
    (/node_modules(\\|\/).*\.d\.ts$/.test(tsResolutionResult.resolvedFileName) && resolutionResult.resolvedFileName.endsWith('js')) {
    ...
}

This doesn't seem the cleanest to me but I do think it would fix both the original issue and our issue (tested locally for us and it works - will have to clone the repo and get it tested for the original issue).

Thanks!