• Part 1: Setting up Gulp with Visual Studio
• Part 2: Getting SASSy
• Part 3: Deployment: minification and concatenation
• Part 4: Code quality: tests and linting
• Part 5: Thoughts on Gulp

In this post I want to talk about JavaScript code quality.

Code quality: tests and linting

JavaScript is a notoriously quirky language –  the tricky “this” operator, lack of block level scoping, the ability to use variables before declaring them, “==” vs “===”, etc etc.

We can do a number of things to tighten up our code quality. We can run tests to ensure our code works as expected, and we can run a linting program to catch any syntatic mistakes before running our code. Combining this with Gulp gives a nice workflow for development.

Linting with JSHint

Linting is a process of running a program to analyse code for potential problems, catching bugs before the program gets executed. Douglas Crockford created JSLint in 2011, and of course there is a gulp plugin for it. However, I prefer to use JSHint – a community offshoot of JSLint that allows for more customisation and is slightly more relaxed in its defaults. You can find a good comparison of the two here.

First, I would seperate out any third-party libraries or frameworks you have into their own folder(s). In my opinion this is good practice anyway, but especially if we are running linting – we don’t want failures on code we haven’t written! Next, we want to add the plugin to our package.json:

{
  "scripts": { "install": "echo Done" },
    
  "devDependencies": {
    "gulp": "~3.9.0",
    "gulp-load-plugins": "~0.10.0",
    "gulp-jshint": "~1.11.2",
    // other plugins here
  } 
}

Then, add the Gulp task to our gulpfile:

var sources = ['./Scripts/*.js', '!./Scripts/libs/*.js'];

gulp.task('watch-lint', function () {
    gulp.watch(sources, ['lint']);
});

gulp.task('lint', function () {
    return gulp.src(sources)
        .pipe(plugins.jshint({
            strict: true,
            predef: [""]
        }))
        .pipe(plugins.jshint.reporter('default'))
        .pipe(plugins.jshint.reporter('fail'))
    ;
});

Here’s a line by line breakdown of the important stuff:

• Line 1: Define the JavaScript files we want linting, excluding any third party libraries and frameworks
• Line 3-5: Set up a watch to run the linting task whenever we make a change to our JavaScript
• Line 7: Set up our linting task
• Line 8-12: Send our files to JSHint. JSHint has a number of options you can set to define how lenient or strict you want it to be. You can look at the docs to get an idea of what you can set. Here I’m only using the strict option (here is a good blog explaining strict mode). There is also a section to define any global variables you’re using that should be ignored – for example if you’re using Angular you’ll want to add “angular” here
• Line 13-14: Send the output of the linting to some inbuilt reporters – one to output the results to console and one to raise an error for any failures

Now we can add the watch task to our default task, and we’ll have linting every time we change our code.

Tests with Karma

One of the great things about Gulp is that you can get a Gulp task to run other Node based packages directly. For example, you can run Karma within a task, without having to use a plugin. Combined with PhantomJS, a headless browser, you get a great unit testing framework for your JavaScript. First, add the packages:

{
  "scripts": { "install": "echo Done" },
    
  "devDependencies": {
    "gulp": "~3.9.0",
    "karma-jasmine": "~0.3.6",
    "karma": "~0.13.9",
    "karma-phantomjs-launcher": "~0.2.1"
    // other plugins here
  } 
}

Then, we’ll need to add our karma config file (karma.conf.js) at the root of the project :

module.exports = function (config) {
    config.set({
        files: ['./Scripts/*.js',
                './Scripts/Specs/**/*.js',
        ],

        exclude: ['./Scripts/libs/*.js'],

        frameworks: ['jasmine'],

        autoWatchBatchDelay: 1000,

        reporters: ['progress'],

        browsers: ['PhantomJS']
    });
};

One thing I’ve found using Karma in Visual Studio: often Karma can crash in Visual Studio with an “EBUSY” error. I haven’t found an adequate explanation for this yet – I think it’s because when you modify and save a file Visual Studio writes a temporary file to replace the file you are saving, which doesn’t sit well with Node. This can be mitigated by setting the “autoWatchBatchDelay” to 1000, which waits 1 second after any change before running tests.

Finally, our gulp task:

var Server = require('karma').Server;

gulp.task('runTests', function () {
    new Server({
        configFile: __dirname + '/karma.conf.js',
        singleRun: false
    }).start();
});

Here, we are simply firing up Karma from within a Gulp task and passing in our karma config file. We are also telling Karma to watch our files for any changes and re-run our tests if they change. If you are going to run this task on a build server (and you should), you’ll need to configure the singleRun variable here. This can be done by using yargs to pass in a variable to switch this behaviour.

There we are! There is a commit of all the changes here, which includes a sample test. I highly recommend using both linting and unit tests when writing JavaScript code, and Gulp is great at running these tasks for us.

Next, in the last past I want to share my thoughts on Gulp, specifically within the .NET ecosystem.

While ngMessages is good, there is no way of providing detail on validation failures. For example, if a text input has to be at least 5 characters long, you can provide a message saying “your entry is too short”, but not “your entry needs to be at least 5 characters”. This is frustrating for an end user, who would need to keep entering characters until they reach the unknown limit. You could hardcode the limit into the validation message for the input, but this would defeat re-usability which is one of the main benefits of ngMessages.

Therefore, I’ve come up with a directive that provides re-usable, informative validation error messages. It works with HTML validation attributes as well as custom validators. You provide a template with the error messages (much like ngMessagesInclude). This template can access the property of each validation attribute and use it to display a more informative message.

A Plunkr is available here.

To use it, add the validator.js code and ngMessages to your Angular app. Then, create a template for the error messages:



N.B: the “startWith” message is for a custom validator that checks that the input starts with a particular character.

The containing div with “ng-messages” needs to be kept as is, while the inner divs containing the validation messages can be changed to your own custom message. Note the binding within each message.

Next, we can use the validator and the template on an input:


< input type="text" name="exampleTextBox" ng-model="name" minlength="5" maxlength="10" start-with="s" validator="validation-messages.html" />


In the last attribute, we specify we are using the validator and pass in the location of the template to use. Also note you must give the input a name and use ngModel for the validator to work.

Now, if we try to enter some input that is fewer than 5 characters, greater than 10 or doesn’t start with s we get a friendly error message telling us exactly what went wrong and why. If we fail more than one validation, we get a message for each failure.

The name of the binding within each message matches the name of the validation attribute, and the value it is bound to matches the property value of the attribute. So, “Please enter at least {{ minlength }} letters” for minlength=”5″ becomes “Please enter at least 5 letters”.

You can see a fully working example in the Plunkr.

Next time, I’ll go through the code for the validator directive.

SQL interprets a DATETIME of the format “yyyymmdd” differently to “yyyy/mm/dd” or “yyyy-mm-dd”. The former is “unseperated” while the latter is “seperated”, and the “seperated” format depends on the current language and date format of SQL Server. If you have the date format set to the British standard “dmy” (as I did), then the month and day portion of the input get swapped. This can cause an error of “The conversion of a varchar data type to a datetime data type resulted in an out-of-range value” if the last two digits are greater than 12, as SQL Server attempts to use the greater than 12 number for the month.

Alternatively if you have a number less than or equal to 12, you won’t get an error but you will return incorrect data. This is much more confusing and much more problematic.

For example, the following queries (on AdventureWorks) are identical, except for the format of the date in the query. The first is “unseperated”, the second is “seperated”:

Query 1 (unseperated):
SELECT [DueDate], [OrderQty], [UnitPrice] FROM [Purchasing].[PurchaseOrderDetail] WHERE DueDate > '20060410'
Query 2 (seperated):
SELECT [DueDate], [OrderQty], [UnitPrice] FROM [Purchasing].[PurchaseOrderDetail] WHERE DueDate > '2006-04-10'
If you run these with the dateformat set to ‘dmy’ (SET DATEFORMAT ‘dmy’) you’ll see that the second query returns data from the 4^th January rather than the 1^st April.

This affects DATETIME, but works correctly for DATE and DATETIME2. Converting the string to either DATE or DATETIME2 only brings in data after the 1^st April, as expected:

DATE:
SELECT [DueDate], [OrderQty], [UnitPrice] FROM [Purchasing].[PurchaseOrderDetail] WHERE DueDate > CONVERT(DATE, '2006-04-01')

DATETIME2:
SELECT [DueDate], [OrderQty], [UnitPrice] FROM [Purchasing].[PurchaseOrderDetail] WHERE DueDate > CONVERT(DATETIME2, '2006-04-01')
However, SQL automatically converts a string into a DATETIME.

Microsoft recommend using DATE or DATETIME2 over DATETIME: https://technet.microsoft.com/en-us/library/ms187819.aspx