Creating a NodeJS Driven Project

OSD600 Week Nine Deliverable

Introduction

For this week, we were introduced to a few technologies that though interacted with during our contributions and coding, were never described or explained the ‘why’, ‘how’, or even the ‘where to start’ aspects. The platforms on trial? Node, Travis CL and even ESLint -curse you linter, for making my code uniform.

Init.(“NodeJS”);

The first process was simply creating a repository on GitHub, cloning it onto our workstations, and then letting the hilarity of initializing a new NodeJS module occur. Why do I cite such humour for the later task? Because I witnessed few forget which directory they were in, thus initializing Node in their Root, Developer, You-Name-It folder; anything but their repository’s cloned folder. Next, was learning of what you could, or could not, input into the initialization commands. Included below is the example script which was taken from Dave’s README.md which showed how the process should look for *Nix users. Window’s users had a more difficult time, having to use their Command Prompt instead of their typical Git Bash terminal which would fail to type ‘yes’ into the final step.

Creating The Seneca Module

The next step was to create the seneca.js module, which would be expanded upon in further labs. For now, we had to write two simple isValidEmail and formatSenecaEmail functions respectively. This task took minutes, thanks to W3 School’s email validation regular expression, which along with my code, is included below. The bigger challenge, was getting ESLint to like my code.

Depending On ESLint

ESLint, up to this point I had only dealt with in small battles, waged on the building process of Brackets where my code was put against its rules. Now, I am tasked with instead of conquering it (in the case of a developer, meaning to write code which complies with the preset rules), but creating the dependency which will build it into my development environment of the project. Installing ESlint requires the following command, followed by the initialization which will allow you to select how you’d like the linter to function along with style guides. The process that we followed is below.

Running Eslint manually would involve running $ ./node_modules/.bin/eslint , which could then be automated by adding the following code to the package.json file.

This would allow for one to call linting at any time, with the npm command followed by “lint” in this case.

Travis CI Integration

When writing the next evolutionary script, program, even website for that matter, you want to ensure that it works, and once it does ‘work’, you double check on a dedicated platform. That’s where the beauty which is Travis CI comes to play, allowing for automated tested (once properly configured) of your projects and repositories. We were instructed to integrate Travis with this exercise with Dave’s provided instructions below.

Now that we have the basics of our code infrastructure set up, we can use a continuous integration service named Travis CI to help us run these checks every time we do a new commit or someone creates a pull request. Travis CI is free to use for open source projects. It will automatically clone our repo, checkout our branch and run any tests we specify.

  • Sign in to Travis CI with your GitHub account
  • Enable Travis CI integration with your GitHub account for this repo in your profile page
  • Create a .travis.yml file for a node project. It will automatically run your npm test command. You can specify “node” as your node.js version to use the latest stable version of node. You can look at how I did my .travis.ymlfile as an example.

Push a new commit to your repo’s master branch to start a build on Travis. You can check your builds at https://travis-ci/profile//. For example, here is my repo’s Travis build page: https://travis-ci.org/humphd/Seneca2017LearningLab

Follow the Getting started guide and the Building a Node.js project docs to do the following:

Get your build to pass by fixing any errors or warnings that you have.

Once that was complete, the final step was to integrate a Travis CI Build Badge into the README of our repository. This final step stood out to me, for I had seen many of these badges before without prior knowledge as to their significance. Learning how Travis CI could automate the entire integration testing of your project on a basic Ubuntu 12.04 (if configured to that) machine within minutes has opened my eyes up to a new form of development testing, implementation, and more open-source goodness. The final repository with all that said and done can be found for the curious, here.

Leave a Reply

Your email address will not be published. Required fields are marked *