Posts Tagged

visual studio code

How to debug Jasmine-es6 in visual studio code

This article is going to show the configuration required to debug Jasmine-ES6 in Visual studio code.
Jasmine-ES6 is a Helpers and overrides that augment Jasmine for use in an ES6+ environment. It is great when you have a project that you do not want to transpile using babel. And it turned out to be one of the NPM package that was used in one of the latest project in which I was involved.
Due to the nature of the plugin, it is not possible to Debug Jasmine-es6 directly in the browser, but it is possible by using the debug feature provided by Visual Studio Code. The settings that are going to be provided below, will actually work to emulate any NPM command that you are currently using.

Create a debug configuration file in Visual Studio Code.

Visual studio code enables use ( sometimes with the use of extension) to debug almost any coding language (js, c#, php,ect..).

To access the Debug page we need to click the “bug” icon on the left hand menu.

Now that we have accessed the debugging page, we are able to add our configuration. To do so, click on the dropdown next to the Green arrow, like shown in the image below.

Visual Studio Code (VSC) will provide you a list of “predefined” debugging configuration that will support you in completing the setup. In our case we are going to use the “launch program” option.
visual studio code available configuration
Our configuration file will look something like this:
Visual studio Code basic debug file
 
  1. {
  2. "version": "0.2.0",
  3. "configurations": [
  4. {
  5. "type": "node",
  6. "request": "launch",
  7. "name": "Launch Program",
  8. "program": "${workspaceRoot}/app.js"
  9. }
  10. ]
  11. }
The configuration can have multiple entry that can be accessed by the dropdown previously used.

Setting the config

The config requires two main information. The first is the Program that we would like to run, this can actually be changed with whatever program you are currently running from the command line. When writing a command you will probably just use the name of the package ( depending how it is installed ), for example “Jasmine init”.

Node will automatically know that you are looking in reality for a package within the node_modules folder called Jasmine. Unfortunately our Debug configuration file is not that clever and will require you to specify the complete path.
You can use ${workspaceFolder} to select the workspace root, and then form the rest of the path required to reach the entry js file of your package. In the case of Jasmine-es6 the path will look something like:
jasmine-es6 path
 
  1. "${workspaceRoot}/node_modules/jasmine-es6/bin/jasmine.js"
Running the above is the equivalent of running the command Jasmine-es6 in the command line. This will work, but in our case we want to be more specific and actually just run a specific spec file.
In a command line scenario I would run the following line:
Jasmine command line
 
jasmine-es6 "/tests/Tests1spec.js"
To add parameter in our configuration we need to use the specify the args array:
Args array
 
  1. "args": [
  2. "${workspaceFolder}\\tests\\Tests1spec.js"
  3. ]
If you use backslash instead than forward slash, you will have to escape them ( as shown above)

Conclusion

The above post is aimed at supporting you and hopefully save you some time. The debugging feature of Visual Studio Code are quite extensive ( I debugger PHP in the past and it worked perfectly).  Not that everything is set up, you can start debugging by clicking the green arrow in the debug page, or just by pressing F5 from your keyboard (make sure to add breakpoint where you would like the add to break).

There may be better method to debug, and most people would have webpack setup to support them in the traspilation and test run, but I wanted to go against current and try something different.

As always I am happy to receive any comment that can support the future readers.

I complete the post wit the complete file below:

Node Program debug in Visual Studio Code
 
  1. {
  2. // Use IntelliSense to learn about possible Node.js debug attributes.
  3. // Hover to view descriptions of existing attributes.
  4. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  5. "version": "0.2.0",
  6. "configurations": [
  7. {
  8. "type": "node",
  9. "request": "launch",
  10. "name": "Launch Program",
  11. "program": "${workspaceRoot}/node_modules/Jasmine-es6/bin/jasmine.js",
  12. "args": [
  13. "${workspaceRoon}/tests/Test1spec.js"
  14. }
  15. ]
  16. }

 

Write cleaner Javascript code with Eslint

Javascript has a bad reputation, and this is mainly due to the fact that it is too flexible to use. Many users would abuse this great feature of this language writing code that is very inconsistent and hard to follow. For example, simple inconsistency like single or double quote around strings, can make project seem quite unclear and messy.

In recent years, after I have been exposed to different languages that follow a more rigid approach to coding standards, I have started to focus to write cleaner Javascript, and I would like to share some of these experiences.

JavaScript, is especially prone to developer error due to its lack of a compilation process. Linting tools allow developers to discover problems with their JavaScript code without the need of executing it. In this article I will be going into details on how you can  use and configure a lint utility to support you.

What is Eslint

Eslint is a pluggable linting utility created by Nicholas Zokas in June 2013, that can be used to analyse our Javascript code to highlight errors on the fly, supporting a quick and clean development.

There are many linters around, but I am listing below some of the reasons that have supported my decision to choose Eslint:

  • It is open source.
  • Great documentation.
  • Huge number of configurations
  • Good examples
  • Works with all major IDE and Code editors.
  • Can be used from the Command Line
  • Works on Build Server

Getting started with Eslint

Eslint requires Node,js to be installed on your machine, so if you do not have it, please download the latest stable release from the main website.

Install

After Node.js is up and running, we can move to the next step by opening a Command Prompt and installing the Eslint package from NPM (visit the NPM website for more information regarding its usage).

Install eslint package globally
 
  1. npm i -g eslint

Configure

Following the installation above, we now have to define a configuration file called .eslintrc.json. Eslint comes with an handy feature to support you in creating this file. To trigger it, access the root location of your site and type the following command

Create eslint config file
 
  1. eslint --init

This command will return three options:

  1. Ask a couple of questions to define the configuration required
  2. Use a popular styleguide ( this will require an existing NPM package)
  3. Inspect your Javascript Files (not suggested if your coding style is inconsistent)

The above will be displayed in the command prompt like shown by the image below:

eslint --init options

For the purpose of this blog post, I am going to provide my own configuration file that need to be extracted in the root of your site. The file can be downloaded by clicking the following link:

Eslint Configuration File

Run the linter

After successfully complete the above steps, you will now be able to use Eslint by using its extensive CLI (command line interface) commands or within most of the major IDE (mode details to follow). The most basic command would just include the file or path to test, for example the following two example will respectively test file.js and all files within the “site” folder

eslint run
 
  1. eslint "c:/site/file.js"
  2. eslint "c:/site"

Configuration File explained

Now that we have Eslint fully configured, it is time to dive into the configuration file to see how a configuration file is structured, and what configurations are set in our setup. As mentioned above, there are hundreds of configurations, all well documented on the Eslint website.

Root & Environments

Section one
 
"root": true, //this will set this file and folder as the root directoty
    "env": {//load common environment/plugin configuration
        "browser": true,
        "commonjs": true,
        "es6": true,
        "node": true,
        "jquery": true
    }

The first section of our configuration file includes the root setting. This is an optional setting that define the root of your project. Projects can have more than one Eslint configuration file, and when running it, it will search in the current folder and all its ancestors until it finds the root value.

The next setting used is the env (environment). Using this setting will load specific environment setting. For example in the case above we are allowing the use of ES6 notation, therefore we would not have any error triggered if using the arrow notation =>.

Globals

Globals eslint
 
"globals": {
        "exampleGlobalVariableName": true
    }

The global configuration accept a object that will determine global variables that we can use within our JS files, without the need to be declared. Failing to do so, will trigger a no-undef error.

For example, when we added jQuery in the env setting above, has indirectly set a global for $ and jQuery variables. This setting is really useful to support the user to understand unexpected dependencies that you may have, that will result in hard unit testing.

Rules

Most of the configuration have three simple settings.

  • off – This configuration is self explanatory. It will switch the error off.
  • warn – This setting will trigger a Warning error. In many IDE warning are displayed with a Yellow underline.
  • error – This setting will return an error. A file could have some warning, but you should always aim for “error free” files.

Some specific rules have more arguments that can be used, but I will be wasting time trying to explain them, as the Eslint documentation is really complete.

Using Code Editors

Eslint CLI is fantastic, but I do not expect you to run it every single time you modify a file, and even if the linter gives you the line number for it, it would still be hard to use on a daily basis.

Luckily for us, Eslint is very easy to set up in most of the major code editors. In this section of the article, I am going to show how you install the linted on Visual Studio Code, that is my editor of choice.

Visual Studio Code

To use Eslint in the editor, we need to first install the official extension called ESlint. To access the extension page click the Extension button on the left menu or click Ctrl+ Shift + X (on windows).

After installing the above extension, you will be required to restart the editor for the effect to take place.

On restart, assuming your Eslint configuration file is in the correct folder, you will be able to immediately see errors highlighted in real time.

The screen shots below show some of the feature available when enabling the extension.

 

Conclusion

I have personally doubt the need for a tool like this, but now after using it, I cannot live without. The configuration that I have shared is a personal choice and I am more than happy for you to use it if you wish to, but at the same time, you should also dive into the available rules and see if there is anything that fit your guidelines.

Start to use a linter is just the first step to write cleaner code. No matter if you are a single developer or work in a big team. Introducing this tool will increase the quality and readability of your code. We have all been guilty of being sometimes lazy to keep our project consistent and lacking structure, but now the tools are available and we have no excuse but to start and write cleaner Javascript.

 

"