Incorrect coverage for @Inject annotation in constructor parameters.

[wawyed]

We've had this issue for a while now and I was wondering if there's was a way to fix it. Seems like for some reason when we use @Inject the branch coverage goes down and we have to add exceptions for all this files, which is less than ideal.

EDIT:

Looking at the javascript I can see this lines:

__cov_NNIkqNquRPx$qWAmG6gCfg.s['37']++;
        __decorate([core_1.Input(), __metadata('design:type', (__cov_NNIkqNquRPx$qWAmG6gCfg.b['15'][0]++,
        typeof (_a = (__cov_NNIkqNquRPx$qWAmG6gCfg.b['16'][0]++,
        typeof model_form_config_1.IModelFormConfig !== 'undefined') && (__cov_NNIkqNquRPx$qWAmG6gCfg.b['16'][1]++,
        model_form_config_1.IModelFormConfig)) === 'function') && (__cov_NNIkqNquRPx$qWAmG6gCfg.b['15'][1]++,
        _a) || (__cov_NNIkqNquRPx$qWAmG6gCfg.b['15'][2]++,
        Object))], ModelFormComponent.prototype, 'mhrModelFormConfig', void 0);
        __cov_NNIkqNquRPx$qWAmG6gCfg.s['38']++;
        ModelFormComponent = __decorate([core_1.Component({
            selector: 'mhr-model-form',
            templateUrl: '/base/src/app/shared/business-components/model-form/model-form.html'
        }), __param(1, core_1.Inject('mhrModalDialog')), __metadata('design:paramtypes', [(__cov_NNIkqNquRPx$qWAmG6gCfg.b['17'][0]++,
        typeof (_b = (__cov_NNIkqNquRPx$qWAmG6gCfg.b['18'][0]++,
        typeof forms_1.MhrDynamicFormFactory !== 'undefined') && (__cov_NNIkqNquRPx$qWAmG6gCfg.b['18'][1]++,
        forms_1.MhrDynamicFormFactory)) === 'function') && (__cov_NNIkqNquRPx$qWAmG6gCfg.b['17'][1]++,
        _b) || (__cov_NNIkqNquRPx$qWAmG6gCfg.b['17'][2]++,
        Object), (__cov_NNIkqNquRPx$qWAmG6gCfg.b['19'][0]++,
        typeof (_c = (__cov_NNIkqNquRPx$qWAmG6gCfg.b['20'][0]++,
        typeof IMhrModalDialog_1.IMhrModalDialog !== 'undefined') && (__cov_NNIkqNquRPx$qWAmG6gCfg.b['20'][1]++,
        IMhrModalDialog_1.IMhrModalDialog)) === 'function') && (__cov_NNIkqNquRPx$qWAmG6gCfg.b['19'][1]++,
        _c) || (__cov_NNIkqNquRPx$qWAmG6gCfg.b['19'][2]++,
        Object)])], ModelFormComponent);
        __cov_NNIkqNquRPx$qWAmG6gCfg.s['39']++;
        exports.ModelFormComponent = ModelFormComponent;
        __cov_NNIkqNquRPx$qWAmG6gCfg.s['40']++;
        var _a, _b, _c;

I believe this lines aren't going to be covered:

        typeof IMhrModalDialog_1.IMhrModalDialog !== 'undefined') && (__cov_NNIkqNquRPx$qWAmG6gCfg.b['20'][1]++,
        IMhrModalDialog_1.IMhrModalDialog)) === 'function') && (__cov_NNIkqNquRPx$qWAmG6gCfg.b['19'][1]++,

This is the js code without coverage:

__decorate([
    core_1.Input(),
    __metadata("design:type", typeof (_a = typeof model_form_config_1.IModelFormConfig !== "undefined" && model_form_config_1.IModelFormConfig) === "function" && _a || Object)
], ModelFormComponent.prototype, "mhrModelFormConfig", void 0);
ModelFormComponent = __decorate([
    core_1.Component({
        selector: 'mhr-model-form',
        templateUrl: '/base/src/app/shared/business-components/model-form/model-form.html'
    }),
    __param(1, core_1.Inject('mhrModalDialog')),
    __metadata("design:paramtypes", [typeof (_b = typeof forms_1.MhrDynamicFormFactory !== "undefined" && forms_1.MhrDynamicFormFactory) === "function" && _b || Object, typeof (_c = typeof IMhrModalDialog_1.IMhrModalDialog !== "undefined" && IMhrModalDialog_1.IMhrModalDialog) === "function" && _c || Object])
], ModelFormComponent);
exports.ModelFormComponent = ModelFormComponent;
var _a, _b, _c;

Interesting enough when I compile my code using tsc I get this output:

__decorate([
    core_1.Input(),
    __metadata("design:type", Object)
], ModelFormComponent.prototype, "mhrModelFormConfig", void 0);
ModelFormComponent = __decorate([
    core_1.Component({
        selector: 'mhr-model-form',
        template: "<mhr-form [model]=\"dynamicForm$\" (onDelete)=\"remove()\" [mhrUnsavedChanges]=\"{ formContainer: formContainer }\"></mhr-form>"
    }),
    __param(1, core_1.Inject('mhrModalDialog')),
    __metadata("design:paramtypes", [forms_1.MhrDynamicFormFactory, Object])
], ModelFormComponent);
exports.ModelFormComponent = ModelFormComponent;

Since IMhrModalDialog is an interfaces and won't exist at run time, the question is why is that code there.

Any suggestions?

[erikbarke]

This is what I've found so far:

• When compiling the the whole project, karma-typescript uses the same Typescript API as tsc, which produces an output similar to the output you got with tsc.

• The Transformation API (when using, for instance, karma-typescript-angular2-transform) recompiles the transformed Typescript files, one at a time, using ts.transpileModule which obviously does things a bit differently, producing the output with the extra interface code. I think this is what breaks the coverage.

I'll investigate some more to see if it's possible to change the behavior of ts.transpileModule or if there's another way of recompiling single files.

[wawyed]

I see, I was baffled when I was looking at your source code for the compile since it looked really similar to gulp-typescript, I didn't think of the angular2-transform!

Thanks for looking into it :)

[erikbarke]

This is somewhat related: microsoft/TypeScript#16872.

Is does kind of make sense though, when transpiling a single module there's no way of knowing if a referenced module is an interface that could be omitted, so the compiler includes what it finds in the file being compiled... Also, recompiling the whole project in the transforms API would be both slow as molasses and probably break a lot of existing code out there 😞

There might be a workaround here, it's now possible to transform the transpiled javascript code (see #153, on the next branch). Using that new functionality maybe you could simply tell Istanbul to ignore those extra lines of code?

[wawyed]

Is there any particular reason why the transform needs to modify and recompile the individual typescript files? Couldn't it change them as typescript and pass them to the full compile instead?

Also don't you find it a bit confusing that because I'm using the Angular2 transform the JavaScript output is different than my dev/dist build JavaScript, taking into account that unit tests should use the same code prod will use if/when possible IMHO.

I can see how the workaround might work, Although, I find it cumbersome that I need to add comments to my source code just for a plugins sake.

Btw, don't take it the wrong way, I'm not trying to be rude or anything, just giving me honest opinion.

[erikbarke]

Here's the whole compiler/transforms chain:

• All files in the project are compiled using the Typescript compiler API
• The emit output for each file consists of:
  • The transpiled javascript
  • A sourcemap
  • An abstract syntax tree (AST)
• The original Typescript code and its AST are fed to the transforms chain
• The Angular2 transform traverses the AST, looking for any templateUrl nodes etc
• If any templateUrl is found, the transform plugin uses the line and column numbers in the AST to modify the Typescript source code
• Since the Typescript code now has changed, it now needs to be recompiled to reflect the changes
• The recompile is done using ts.transpileModule which, by design, produces a slightly different output
• Kaboom

So, I guess it's back to the drawing board...

Since plugins now have the ability to modify the transpiled javascript without having to jump through the recompilation hoop, here's an idea I'm toying with regarding the angular transform:

• Check if the transpiled javascript contains the string "templateUrl" etc
• If it does, create a temporary AST and traverse it to find the line and column numbers
• Modify the transpiled javascript

Pros: the Typescript code will get transpiled only once and in a consistent way
Cons: this adds a lot of steps; creating another AST, maybe the sourcemap needs to be recreated, it's more or less a complete rewrite of the plugin

Thoughts?

[wawyed]

I don't think the sourcemap would need to change since all you are doing is replacing a string with another one.

I might be oversimplifying this but, would a RegExp against the transpiled javascript not suffice for what you are trying to achieve instead of building an AST of the typescript file?

[erikbarke]

Yeah, I experimented a bit with using an AST, but ended up going for the RegExp approach. It feels as "safe" as using an AST with one drawback being that the plugin will also modify templateUrls and styleUrls inside multiline comments, but that shouldn't break anything during the test run. If it turns out this is a problem somehow and proves to be too hard to fix (regexping my way around code comments isn't exactly my idea of fun...), I can always go back to using an AST as a plan B.

If you want to test this, you need to install both karma-typescript and karma-typescript-angular2-transform from from their "next" branches:
npm i github:monounity/karma-typescript#next
npm i github:monounity/karma-typescript-angular2-transform#next

☺️

[wawyed]

Just tried your new version. All test passed and coverage looks correct hooray :D