vblain / vuejs2-typescript-starter

VueJS2 starter with Typescript, Webpack, code-splitting, unit tests (karma) & code coverage with ASP.NET Core 2.0 server

VueJS starter

Base

so the base for this project is the ASP.NET Core vue SPA template that ships with 2.0 of ASP.NET core.

Why

Basically digging around and tweaking things, found a bunch of things that could be improved in general. Should help future me when I want to build an actual web UI. A few of the things

1. Upgraded to latest Vue(2.3.2 → 2.4.2) and Typescript (2.3 → 2.4)

2. Got rid of awesome-typescript-loader and got back ts-loader which lets you import .vue components easily.

3. Added examples of simple components, slots and vuex.

4. Added example of unit testing components with avoriaz and plain vue with karma, mocha, chai & sinon.

5. Unit test runs report code coverage tracked back to original Typescript source.

6. Updated webpack config to handle debugging tests with source map support - meaning you can place breakpoints directly in Typescript code when debugging in Chrome.

7. Added examples of bundling components into chunks - Vue Async Component + webpack’s code splitting feature.

8. Hooked in babel-loader in webpack - so ts transpilation path is TS ---ts-loader--→ ES2015 ----babel-loader-→ ES5. This lets us use the dynamic import statement in TS 2.4 for defining async components.

9. Removed .vue.html extension and named back to .vue - works better with the vetur plugin under VS Code.

Getting started

1. Clone this repo

2. Run npm install

3. set ASPNETCORE_ENVIRONMENT=Development

4. Run it with dotnet run

5. Visit localhost:5000/

To run client side tests

After you have done npm install run npm run test

Notes - Unit testing and code coverage.

Getting Karma, webpack and code coverage to play nice with each other took some doing. As of this writing (Sep 2017), karma coverage was broken when used with ts transpilation and html report generation fails with error.

1. For getting code coverage across all your code, you need to create an index.js which pulls in all your tests and all your sources.

2. In karma.conf.js, we set env={test:1} and then require our webpack conf. Within webpack config, we instrument sources with istanbul-instrumenter-loader based on test being true.

3. In a test build, we also add a rule for building ts files under test without the instrumenter.

4. In karma config, we replace karma-coverage with karma-coverage-istanbul-reporter

Notes - Debugging unit tests with Karma & sourcemaps

A good dev experience is critical - so being able to debug unit tests in browser is important. Since the source gets transpiled before it reaches the browser, having source map support is super critical. Getting this to work again was jumping through hoops - karma and webpack handovers aren’t exactly well documented. In the end, I could get it to work only with the following:

1. Don’t include code coverage instrumentation while debugging - pretty self evident.

2. Include inline source maps in test/dev builds

           .concat(isDevBuild || isTestBuild ? [
               // this is required for source map debugging
               new webpack.SourceMapDevToolPlugin({
                   filename: null, // only inline source maps seem to work when debugging with chrome
                   moduleFilenameTemplate: path.relative(bundleOutputDir, '[resourcePath]'), // Point sourcemap entries to the original file locations on disk
                   test: /\.(ts|js|vue)$/
               }),
           ] : [
           // prod config
           ]

3. Use karma-sourcemap-loader in karma conf