Creating a VueJS+TypeScript project

As I’ve mentioned before, the VueJS and TypeScript teams are working to get closer. I don’t have the sense that VueJS plans to replace Javascript, but there’s at least a sense that support for TypeScript is a good thing to do. When vue-cli 3.0 comes along, it will include direct support for TypeScript projects. For now (as of 5/30/2018), we can either add the TypeScript support by hand or we can use a beta version of vue-cli to set things up.

But I’m getting ahead of myself — let’s take this in steps.

Installling nvm

The project we’re taking on at PixelFab has both a client and a server component, which means we’re looking at node.js solutions on both sides of the wire. When you put software up in a production environment, it’s useful (actually: vital) to be building on a stable platform. You certainly want to consider both point updates and major version updates, but you don’t want to adopt them without some testing and validation. Especially so if you have customers actually running your stuff in live production. Enter nvm, which allows you to set up multiple versions of node.js simultaneously and run/test them side-by-side.

I’m both a Mac and a Windows user. Each has it’s place, and we need to test on both in any case, so that’s probably a good thing. On a Mac, installing nvm is dead easy. You can do it with HomeBrew (or MacPorts), or you can install it directly off of the website:

# WARNING: Medium breaks lines in code when it shouldn't!
# You should cut and paste this to a text editor to see what
# it actually says!
touch ~/.bash_profile
curl -o-https://raw.githubusercontent.com/creationix/nvm/v0.32.1/install.sh | bash

Installing nvm on Windows is a bit more involved. I ended up using the nvm-windows on my Windows PC with some reservations.

The problem with both of these installs is that you are trusting not just the designer (and the packager) of nvm, but also anyone who compromises their repository. That bash shell that runs on OSX or Linux? It can do anything you can do. It would really be helpful if a more trustworthy install process for nvm existed, but it doesn’t — yet.

Installing nvm isn’t strictly necessary. The reason to use it is that it lets us maintain multiple simultaneous versions of Node.js. Notably: it lets us maintain the “in production” version even as we are developing the next production version with a possibly newer version of Node.JS

Installing npm

With nvm installed you need to install a suitable version of npm (Node package manager). You can find the most recent stable and development versions of Node.js at nodejs.org. At the time of this writing, the latest stable version is 8.11.2, so that is what I installed:

nvm install 8.11.2
nvm use 8.11.2

Running nvs ls will tell you all of the available versions (allegedly stable and long-term supported), but you may find that the packages and libraries you want haven’t caught up with the latest stable release. Unfortunately you’ll need to try it to find out.

Starting a VueJS+TypeScript Project

As I said above, this won’t be “official” until vue-cli 3.0 is released (which should be soon). Microsoft Research has provided documentation here about how to get started using the current “official” tools. At the time of this writing, an alternative is to use the beta version of vue-cli as follows:

npx -p @vue/cli vue create typescript-project-name

The npx utility lets you run the beta vue-cli without installing it. Ordinarily I wouldn’t recommend this, but once vue-cli has created your project you’re done with vue-cli. If it doesn’t work for some reason, you can delete it and fall back on the Microsoft documentation.

If you use npx to set things up, the choose “manually select features.” The minimal options if you want TypeScript are probably Babel, TypeScript, and ESLint. I chose “router”, “linter/formatter”, “unit testing”, and “E2E testing” as well. The “right” answer has a lot to do with your workflow and your preferred tools. I don’t know enough yet to make any confident recommendations, but these selections are pretty close to what the current version of vue-cli selects. If you’re already familiar with vue-cli you may want to consider other choices.

Some things I did not choose at this time:

• Progressive Web App (PWA): We will probably want this, but I’m a newcomer to Node and to Web Apps, and I want to tackle one thing at a time.
• Vuex: Having some knowledge of functional programming and “state objects” I’m familiar with the idea. Vuex may be a good idea, but I want to experience the problem before I choose a solution. It also may be true that the need depends on the applicaiton.
• CSS Pre-processors: Not knowing what to choose, I left this out.

I elected class-style component syntax, Babel alongside Typescript, ESLint + AirBNB, Lint on Save but not Lint and fix on commit. Jest (arbitrarily) as the testing framework, and Cypress (arbitrarily) as the E2E framework. Those might or might not be the right answer, and they can be re-examined later. I chose to put configurations in dedicated files rather than package.json. I saved my selections as a preset named “ShapIgnorance”, which is a reasonable indicator of my level of confidence.

A note on ESLint: I’ve been pretty happy with what ESLint has shown me in Visual Studio Code. It’s a really impressive tool. The reason not to choose anything that says “fix on commit” is that the last thing you want is some well-intentioned script screwing with your code at the moment of commit. It’s an excellent way to commit broken code!

I was enormously encouraged to see that there were no known vulnerabilities in this base configuration. I was less than thrilled to find that my current version of ESLint may or may not support the latest version of TypeScript.

From a production perspective, 70 packages seems like a lot of things to check, but your needs may be different.

Running

npm run serve

In the created directory, and pointing a browser at the result, produced a more-or-less reasonable result for a skeleton application.

Next Steps

There are two directions to go from here: authentication and authorization or installing more libraries. I decided to tackle authentication and authorization first, mainly because we’re going to need those results pervasively as we design our client/server APIs.

There are three working theories here:

1. The things I don’t understand are the biggest risks because I can’t qualify them.
2. If something in your notional design is catastrophically wrong, you want to know as soon as possible.
3. When something goes catastrophically wrong, there are only two causes: (1) a fundamental failure to of requirements, or (2) an unrevealed dependency in some area you didn’t understand. Stated conversely: you’re unlikely to catastrophically fuck up the things you already know how to do; it’s what you don’t know that bites you in the ass.

A corollary to this is that you should reduce unknowns as soon as it is practically feasible to do so. Doing so increases confidence, reduces stress, and (in the worst case) lets you kill a project for the least expended cost. Sometimes it prompts you to see ways to re-design or re-engineer the project in a way that works around a problem. The one certain rule is: ignorance is not bliss. For those of you old enough to remember the respective programming languages, it’s also true that Ignorance is not BLISS.