Add sourcemap support for coverage by using remap-istanbul #23
Conversation
Added remap-istanbul and all supporting karma plugins to correctly remap the coverage results back to their TypeScript source. Since all generations happens in memory by Webpack, we needed inline sourcemap support, provided by the Karma plugins, the Webpack devtool setting, and the webpack typescript loader. The normal `ts-loader` doesn't support inline sourcemaps, so we switched to `awesome-typescript-loader`. We created a new `tsconfig.test.json` that is the same as the normal `tsconfig.json` but enables inline sourcemaps by adding `"inlineSourceMap": true`. The webpack dist builds have also switched to `awesome-typescript-loader` to keep the configuration consistent. To make the `awesome-typescript-loader` correctly work with const enums, we needed to enable `preserveConstEnums` property in the `tsconfig.json`. We also switched he `test/index.js` to `index.ts` and included `webpack-env` in the `typings.json` so all wepack requires work in TypeScript. To have correct coverage reports consisting of _all_ the source files, we've added a `Dummy.ts` file in the `src/` folder that is not referenced by any tests, but must show up in the coverage results. If this is not the case, we know our test setup is incorrect. re #15
|
Changes Unknown when pulling 97d348e on feature/remap-istanbul into * on master*. |
| @@ -40,7 +40,10 @@ module.exports = function() | |||
| { | |||
| test: /\.ts$/, | |||
| exclude: /node_modules/, | |||
| loader: 'ts' | |||
| loader: 'awesome-typescript-loader', | |||
There was a problem hiding this comment.
I don't mind changing this to awesome-typescript-loader, but if we use a separate webpack config for test we could theoretically still use the 'default' ts-loader here. Maybe we should test the performance of the loaders when we have a bigger test project in skeleton. For now though, let's just use the same loader for both.
There was a problem hiding this comment.
Yeah, the idea was to use the same loader for both tests and distribution builds, so we know that if the tests can correctly run the generated code, the distribution builds should be fine as well.
Still, we use the normal TypeScript compiler for npm builds, so that's a difference we cannot overcome. (The 'default ts-loader is still different than the standalone tsc, so we will never get rid of that difference)
Added fixes and improvements to unit testing from the seng-boilerplate repo: mediamonks/seng-boilerplate#28 mediamonks/seng-boilerplate#27 mediamonks/seng-boilerplate#23 Replaced some mediamonks/seng boilerplate names to knockout-validator equivalents.
Added remap-istanbul and all supporting karma plugins to correctly
remap the coverage results back to their TypeScript source.
Since all generations happens in memory by Webpack, we needed inline
sourcemap support, provided by the Karma plugins, the Webpack devtool
setting, and the webpack typescript loader.
The normal
ts-loaderdoesn't support inline sourcemaps, so we switchedto
awesome-typescript-loader. We created a newtsconfig.test.jsonthat is the same as the normal
tsconfig.jsonbut enables inlinesourcemaps by adding
"inlineSourceMap": true.The webpack dist builds have also switched to
awesome-typescript-loaderto keep the configuration consistent.
To make the
awesome-typescript-loadercorrectly work with const enums,we needed to enable
preserveConstEnumsproperty in thetsconfig.json.We also switched he
test/index.jstoindex.tsand includedwebpack-envin thetypings.jsonso all wepack requires work inTypeScript.
To have correct coverage reports consisting of all the source files,
we've added a
Dummy.tsfile in thesrc/folder that is notreferenced by any tests, but must show up in the coverage results.
If this is not the case, we know our test setup is incorrect.
re #15