Date 16/09/2014
Whether there is just one or more developers working on a given code base, over time it comes difficult to read one's own code if the code style differs. Any shared code should follow certain style guides for making it consistent.
Code validation checks against syntax failures, possible naming collitions and other relevant things that might be needed in order for the code to work in a given set of environments. What works in one browser, might not work in another.
For Node.js, the environment is somewhat stable and while updating patch level (0.0.x) versions, should not break existing code.
Also since is is always made from the same basic components, namely V8, it has somewhat similar runtime expectations
between minor (0.x.0) versions.
Code linting validates and evaluates code against a set of given rules, usually based on code style and validation best practises, as well as personal taste.
Use the repository hello-node-js that was created during the previous lecture.
- Automatic Semicolon Insertion (ASI) is a handy helper found in many browsers, but it is usually best to be avoided
- Found out about ASI and write about it few lines in your
README.md - Validate your code,
task-*.jsfiles against ASI and add a validation configuration file in your repository
- Choose an existing Node.js module from npm which does not have code validation included
- Create a fork from its source
- Add code validation configuration, which would approximately match the existing code style used in that module
- Optional: Create pull request to the module
- Link your pull request or fork to the list below
- Take a look at the source codes of the following linters and observe how they are achieving similar
things differently. Then write down in your
hello-node-jsrepositorylinters-study.mdfile about the similarities and differences, as well as external module usage. Write a short configuration example how to prevent ASI failures, for each three linters
- Optional: Write a rule for one of the three linters
- Create a new repository or clone the original linter project
- Instead of using the
masterbranch, create a new branch with name of your new rule, prepended byrule- - Feeling adventurous: create a pull request to the linter project for adding your rule in it.
- ESLint validation added to node-easyimage / Heikki Alanen
- JSHint validation added to ncht / Joonas Meriläinen
- ESLint validation added to gulp-minify-css / Jukka Rautanen
- JSHint validation added to async / Markus Iivonen
- JSHint validation added to Lo-Dash / Marko Hamppula