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

Upgraded to latest Vue(2.3.2 → 2.4.2) and Typescript (2.3 → 2.4)
Got rid of awesome-typescript-loader and got back ts-loader which lets you import .vue components easily.
Added examples of simple components, slots and vuex.
Added example of unit testing components with avoriaz and plain vue with karma, mocha, chai & sinon.
Unit test runs report code coverage tracked back to original Typescript source.
Updated webpack config to handle debugging tests with source map support - meaning you can place breakpoints directly in Typescript code when debugging in Chrome.
Added examples of bundling components into chunks - Vue Async Component + webpack’s code splitting feature.
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.
Removed .vue.html extension and named back to .vue - works better with the vetur plugin under VS Code.

Getting started

Clone this repo
Run yarn install. # Read Why Yarn below
set ASPNETCORE_ENVIRONMENT=Development
Run it with dotnet run
Visit localhost:5000/

To run client side tests

After you have done yarn install run yarn 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.

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.
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.
In a test build, we also add a rule for building ts files under test without the instrumenter.
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:

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

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
        ]

Use karma-sourcemap-loader in karma conf

Why Yarn (aka Why not NPM)

So when I started this repo, I did not know any better and used npm. And then there were problems!

Background

Package.json only specifies a semver range and w ith packages being updated all the time and front end projects seemingly depending on 10s of packages and then those depending on further packages, it’s a miracle that anything actually works. To get around this and have reproducible builds, NPM generates npm-shrinkwrap.json which you’re supposed to commit into version control. Good - that’s what I did but it turns out that it didn’t do what it said on the tin.

After a few months when I cloned this repo, I started getting weird errors that I did not remember seeing earlier. Ditto for the folks who cloned this repo.

Bottomline - npm-shrinkwrap.json is supposed to give you reproducible set of packages in node_modules only that it doesn’t. Apparently, this is in part due to NPM’s use of non-deterministic resolution algorithm. Should you want to read more, here’s a couple of links - SO: What is the difference between yarn.lock and npm’s shrinkwrap? and Yarn.lock

smattoo/vuejs2-typescript-starter