3 simple ways to improve your productivity and the code quality when writing JavaScript in Visual Studio 2017

Writing JavaScript code without any type analysis superset like TypeScript or Flow is still a thing and in my opinion absolutely valid and welcome decision. Without types there are some implications while coding in JavaScript. Visual Studio does a great job for providing Intellisense and F12 functionality for the files which reside in the same project. We can improve the quality of our code even more.

The _references.js file

JavaScript files outside of the current project cannot be linked and used as reference for code completion while coding. The first way to improve your experience with JavaScript is to use the _references.js file. This way was presented in a previous article I wrote.

The ESLint linter of Visual Studio 2017

The second option you have is to activate the ESLint linter inside you Visual Studio 2017 IDE. In general, a linter is a tool which parses your code and based on some defined best-practices of clean coding it makes suggestions about improvements you can take. A classic example of a bad practice that gets reported from ESLint is the non-use of the var keyword when defining a new variable, which makes the variable automatically global.

Here is the option to activate the feature:

If you are using ReSharper, you also get a JavaScript linter. This one can be tuned even more and there are many rules that you can activate or deactivate.

The checkJs flag in the tsconfig.json file

This one is a brand new feature (Version 2.3). Every .NET project supports the use of a tsconfig.json file. Inside this file you find settings for TypeScript which apply to the current project. The only requirement is that you have installed TypeScript on your machine.

It is absolutely ok to create such a file in a project with no TypeScript code. So go ahead, do it and add the following content in it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true,
    "noEmit": true,
    "noEmitOnError": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    "target": "es5"
  },
  "include": [
    "./Content/Scripts/**/*"
  ],
  "compileOnSave": true
}

As you can see we set allowJs: true and checkJs: true and we automatically get type checking in our JavaScript files!

We activated the check-flags that make sense in JavaScript code like noUnusedLocals, noUnusedParameters, noFallthroughCasesInSwitch, noImplicitReturns. The flag noImplicitAny is only TypeScript relevant and we do not use it here. Here you can find a list of all possible attributes you can use in the tsconfig.json file.

The include: object contains a list of the files that are going to be checked. The double stars means that we recursively check the folders inside the folder Scripts and we search for any JS files.

The TypeScript parser will inform us about issues like the following two:

1
2
3
4
5
var firstName = "Christos";
console.log(firstName);
firstName = 12;

var elements = document.getElementsByTagNAme("input");

If we did not use the type checker we would not get informed about the change of type of the firstName variable. Such use is absolutely fine for JavaScript, since types are only a syntactic sugar from TypeScript, however it makes our code harder to understand and to test.

In the second case of getElementsByTagName we misspelled the name of a standard function but we would get no error from Visual Studio about it. Our application would fail on run-time when it tries to execute the line.

Here are the warnings we get from Visual Studio in case we use the checkJs: true flag:

One more very important thing about checkJs: true is that it also work for inline code (!!), but you will have to have the HTML files opened in order to get checked. This does not count for the JS files, they are all getting typed checked.

Conclusion

I hope one or more of these features are going to help you write better and more clean code. I personally use a combination between the _references.js file, the ReSharper linter and the checkJs: true attribute and I am absolutely satisfied with the amount of issues I could resolve before my code went into the production.