ES2015 module issue with transpileOnly + decorators + interfaces

[RoystonS]

Hi there,

We have a very large Angular 2 codebase that we're attempting to move over to ts-loader; we're getting massive (4-5x) speed boosts compared to our existing awesome-typescript-loader setup, but sadly we're getting compilation issues when we turn on transpileOnly.

It only occurs when:

• Building ES2015 modules AND
• Using a class with a decorator on it AND
• The class uses an imported interface AND
• The imported interface comes from a module that also exports something concrete (e.g. a class or a const)

(webpack complains that it can't find the interface with a stack trace suggesting that it's processing harmony imports.)

I've created a repo with a standalone repro case in it: it's just tiny 2 files both of which are under 10 lines of code:

https://github.com/RoystonS/ts-loader-issue

(Is this related to what's discussed in issue #400?)

Thanks,
Royston.

[RoystonS]

Ah, it's worse than I thought. Even after working around the warnings by moving interfaces to separate files, the actual generated code, is mashed, and the decorator references to even concrete types are broken.

Correct output code in __decorate call (transpileOnly off):

[__WEBPACK_IMPORTED_MODULE_1__ng_core__[\"HttpService\"]])]

Broken output code in __decorate call (transpileOnly on):

[typeof (_a = typeof __WEBPACK_IMPORTED_MODULE_1__ng_core__[\"HttpService\"] !== \"undefined\" && __WEBPACK_IMPORTED_MODULE_1__ng_core__[\"HttpService\"]) === \"function\" && _a || Object])]

[johnnyreilly]

First of all: thanks for the detailed and minimal repro! That's always appreciated.

I'm somewhat intrigued as to what's causing your issue since I'm using similar approaches in this project without anything choking. I'm not sure why that would be.

TBH I'm somewhat time-poor right now and so I'm not likely to be able to look at this directly. That said, I'm happy to try and help you get to the bottom of it if I'm able to. I'd be tempted to advise doing the following:

• fork ts-loader
• put some extra logging in around the transpile emit
• yarn link it into your project

See what, if anything that reveals...

[johnnyreilly]

It may also be worth reading up on this issue: microsoft/TypeScript#18008 - I haven't read it thoroughly but it may be relevant. Also, does dropping emitDecoratorMetadata: true fix the issue?

[RoystonS]

Thanks. I'll take a look at your 'hours' repro and see what's going on there.

Dropping emitDecoratorMetadata: true does stop the warnings appearing (as does removing any concrete export from the module with the interface in).

Our entire codebase only has about 3 instances of this in there, so I've managed to work around the interface warnings by moving the interfaces to their own files. But the generated code is still borked.

[RoystonS]

I've had a look at your 'hours' repo, and out of the box it doesn't choke, as you say, but I can get it to choke with two small changes:

1. Turn on emitDecoratorMetadata: true in the tsconfig.json file
2. Reference an imported interface in a constructor of a decorated class. (That'll cause the compiler to emit metadata about the constructor parameters, which causes the problem.) For instance, add this constructor to src/components/layout/header.tsx:

constructor(props: RouteComponentProps<{}>) {
    super(props);
}

That then produces:

WARNING in ./src/components/layout/header.tsx
41:69-88 "export 'RouteComponentProps' was not found in 'react-router'
    at HarmonyImportSpecifierDependency._getErrors
    ...

This is a big issue for Angular 2+ which is reliant upon such metadata for its dependency injection. It looks like angular/cli is currently using a custom tsc wrapper for its TS compilation, and webpack for the rest of its build, but in our codebase we're using webpack all the way.

microsoft/TypeScript#18008 does indeed look relevant, especially the comment in microsoft/TypeScript#18008 (comment). Interestingly they suggest that the different generated code (a runtime check) that I see with transpileOnly: true is equivalent for interfaces, but it does appear to be incorrect for concrete classes, which is meaning that our Angular 2 components fail to detect their own dependencies.

[johnnyreilly]

It could be worth reporting your experience on the TypeScript issue - they might be able to advise. I'd be interested if you've references to the relevant bit of the Angular cli...

[RoystonS]

Yup, just logged a comment on the TS chain. It's proving a bit hard to find the angular wrapper, but there's a bit here:
https://github.com/angular/angular/tree/626555c01376f2daa8270db27c11606d48898ae6/packages/tsc-wrapped

[olee]

I am also experiencing this issue when I tried to use autobind-decorator on class methods for react components.
Those that use imported interfaces in their parameters start to throw these errors.
Are there any news on this?

[RoystonS]

(I've not investigated further. Our team jumped ship to React as soon as FB changed the licence.)

[Strate]

I use this plugin to remove warning. These warnings are useless, because TS already made a check for export exists. This plugin compatible with webpack 3 and 4

const ModuleDependencyWarning = require("webpack/lib/ModuleDependencyWarning")

module.exports = class IgnoreNotFoundExportPlugin {
    apply(compiler) {
        const messageRegExp = /export '.*'( \(reexported as '.*'\))? was not found in/
        function doneHook(stats) {
            stats.compilation.warnings = stats.compilation.warnings.filter(function(warn) {
                if (warn instanceof ModuleDependencyWarning && messageRegExp.test(warn.message)) {
                    return false
                }
                return true;
            })
        }
        if (compiler.hooks) {
            compiler.hooks.done.tap("IgnoreNotFoundExportPlugin", doneHook)
        } else {
            compiler.plugin("done", doneHook)
        }
    }
}

[johnnyreilly]

The workaround solution suggested by @Strate is very helpful. I'd be open to baking this into ts-loader since it seems to have bitten a few people... Would anyone like to submit a PR?

[johnnyreilly]

BTW I'd only apply the change when emitDecoratorMetadata: true - it doesn't seem to be necessary when this is false

[johnnyreilly]

It looks like there's 3 places in the codebase where errors are registered to webpack. See the top 3 files in this search https://github.com/TypeStrong/ts-loader/search?utf8=✓&q=errors.push&type=

If in each call site we applied @Strate's filter then I imagine that would do the job. If someone wants to POC this and submit a PR we can work on this together. Don't worry about getting tests to pass - I can help with that.

[Roustalski]

I would also like to chime in here. We are using create-react-app with the react-scripts-ts that uses all webpack under the hood and Inverisfy JS for our IOC, and this is popping up all over the place. I'll try out the workaround.