In the last six articles I’ve been doing a study of what it takes to do a node app. For those who are starting here, I had a list of requirements:
- I need to be able to run a small web server
- I need to be able to handle templated views with server-side code
- I need to be able to do social authentication
- I need to be able to use an MVC architecture
- I need to be able to provide a Web API
- I need to be able to publish a node app to Azure
- I need to be able to edit node applications in Visual Studio 2015
This last article is about Visual Studio. By the time you read this, Visual Studio 2015 Release Candidate will have been out about a month. If you have not tried it yet, then you need to do so. It does not come (out of the box) with Node support, but that can easily be added. Just take your browser to the Node.js Tools for Visual Studio site and download the v1.1 BETA Edition. Install it, restart Visual Studio and you are all set.
Creating a new project
In the last six articles I’ve created a pretty cool app that does nothing more than authenticate you against any number of social authenticators – things like Twitter, Facebook, Google and Microsoft. I’m going to leave that behind (well, sort of) and create a new app from scratch using Visual Studio.
Step 1 – “New Project…”
Look at all those choices! It’s good to see a wide variety of template projects, including starter web applications and azure hosting options. I’m going to choose the blank web application with support for hosting in Azure. I’m going to adjust the location to store it in my node-stuff repository. I’m going to call the project “socialauth” to represent what it does. Since I’m not going to have multiple projects in this solution, I’m going to uncheck the “Create directory for solution” box.
Note to self: Don’t check the “Add to source control” when you already have source control set up.
At this point, the project is scaffolding out. Expanding all the folders, here is what you get:
Note the npm/global folder. That’s a virtual folder – it isn’t really there. If you run npm install -g <something> then it places it in a global place in your environment and Visual Studio detects that and shows them to you. This is kind of awesome.
There were a bunch of packages that I used in developing the basic-webapp. So I’m going to edit the package.json to add back everything there. Don’t you just love Intellisense? The Intellisense has full knowledge of the package.json format and does help suggestions for keys and their values. For instance, add "license" to the JSON blob and it drops down a list of open source licenses to include.
When you are typing in dependencies, Visual Studio Intellisense will drop down the semver versions of the latest package. If the package is not in npm, then it will say “Unavailable” – a sure fire indicator that you have typed the name wrong.
When you are done, save the package.json and watch the package manager download all the packages for you. They appear under the “npm” node in the Solution Explorer, but in reality are under node_modules on the file system.
Like to have your package.json properties sorted? There is an option for that. Just click on the multi-talented light bulb:
It only sorts within the block your cursor is on – so, click within the dependencies and select the Sort Properties to sort the dependencies. While we are on the subject of dependencies, light bulb options allow you to update the package and visit the home page:
Start typing. Note that when you type in require, you get intellisense based on your installed dependencies, plus an explanation:
There is a little gotcha here. While you are typing a long multi-line statement, the indenting will be a little weird – it re-formats on the fly to the start of the line. Once you hit that semi-colon, it re-formats it back to the proper indentation. It’s weird, but this is a beta.
Intellisense is helping throughout the process of this with context-relevant suggestions:
Intellisense is more than just giving suggestions on what is next – it provides in-editor documentation pop-ups so you can know what arguments are needed as well.
Could it be better? Sure. In particular, I noticed that the app and server variables were not auto-completed in the server.js file. Had I written this in TypeScript, maybe that would have happened because TypeScript has strong types. Also, the indenting immediately following the multi-line statements was off:
var express = require("express"), http = require("http"); /** * Why is this indented here instead of flush to the left? */
All in all, these are things I can live with. I also bumped into a coloration bug. Hopefully, they will get these minor annoyances fixed before the final build.
In terms of improvements, you will notice that Linters and Documentation are common in all large scale projects. I would love to define a documentation standard (JSDoc) and linter (ESLint) for the project and get those run and verified on every single save.
Editing CSS and HTML is exactly the same as the experience in the Visual Studio 2015 CTP 6, so I won’t delve into it here. There are none of the annoying hangs that I experienced at the end of April, so stablility and performance have been improved significantly here.
Once the code is written, you might want to run it. So, hit the Google Chrome button in the top menu bar to launch the node executable and start the browser. You can also run the program by pressing F5.
This is where the experience is not altogether there. NTVS (Node Tools for Visual Studio) opens up a command window. Why am I not seeing this in a panel within Visual Studio?
As you can see, I have an error. This was deliberate since I wanted to see what would happen. I need this to persist – preferably in an error list where I can refer to it. Also, I want to click on the error and go to the file/line that is causing it. None of those things happen.
Node.js does If you get through to the serving of pages, you can set breakpoints, watch locals, etc. However, that doesn’t help you when the program terminates because of an Exception. Once you get through the initialization, the debugging environment is pretty solid (click on image for bigger view):
Publishing to the Cloud
The last step is to take a look at what is required to publish the app up to the cloud. Right-click on the project and select Publish…
You can create a new web site directly from here. Note that with the command line tools, we were limited to creating a cloud app. Here I can create a Web App:
Don’t forget to change the Auth0 callback address in the Auth0 management console to match the URL you are generating. After this screen, it’s a fairly straight forward process – which ultimately fails. I got the error:
This is actually fairly common because node_modules runs on Windows but it’s really for Linux where the directory depth doesn’t matter. As a result, I have problems dealing with node_modules on a regular basis and this is just one more symptom of that problem.
We’re not quite there yet!
The killer is that final problem – dealing with the directory structure that npm uses. Unfortunately, the node/npm crowd don’t seem willing to deal with this issue.
Let’s be real here: NODE AND NPM DO NOT SUPPORT WINDOWS.
They might claim to support Windows and they may even ship code that runs on Windows, but that is a far cry from supporting Windows. Unless Microsoft steps up to the plate and produces an npm lookalike that actually works, node on Windows is the walking dead. Ok, it might not be that bad since there are workarounds, but support is just not there.
Back to my original quest – could I develop Node applications on Windows? Yes I can, right up to the point where I want to use automated tools to publish them. At that point, I have to switch over to a non-Windows system.
And that’s probably fine.