Read: Class 01 Node Ecosystem, TDD, CI CD - 401-advanced-javascript-muna/amman-javascript-401d1 GitHub Wiki

Use Your Computer Like A Developer

Writing code is difficult enough, don’t allow your problem to be finding code on the file system. You should come up with a system for naming files - don’t deviate from it! Keep all of your projects in one place and always use version control.

File Naming Rules:

  1. Use lowercase for all code file names.
  2. Use kabob-case (“-“ separated words) for all code filenames with multiple “words”.
  3. If you are forcing a file to be first or last in a listing or are calling out importance, it is standard to capitalize the entire filename. Github sets the standard of README.md for this reason.

Node.js

  • Node.js is an open-source framework for writing Javascript on your operating system.
  • It is compromised of the V8 Javascript runtime and the NodeAPIs.
  • V8 supports many features in the latest version of Javascript, called ES6 (or ES2015).
  • V8 is the Javascript runtime developed for the Chrome browser and is written in C and C++.
  • The Node APIs are written in C, C++, and Javascript.
  • Node was developed to enable developers to easily write code with asynchronous input and output (I/O).
  • Node.js uses an event loop that is driven and non-blocking architecture - this enables Node.js to have very low overhead when it is not running.

package.json

  1. The package.json file is used to describe and configure a Node.js package.
  2. The only two fields that are required by a package.json are name and version but we often use npm init or npm init -y to automate the creation of this file.
  3. If a package has external dependencies, they are listed by name and version under the fields dependencies and devDependencies.
  4. If the package depends on an external package to run, the external package should be listed under dependencies.
  5. If the external package is only needed in development (like a testing framework), it should be listed under devDependencies. package.json files can have a scripts field where keys can be associated with unix commands. This gives us the ability to create custom automation scripts.
  6. NPM scripts have the added benefit that they can run any command line utility (CLI) defined in a dependency, without globally installing the CLI on you operating system

Semantic Versioning

The Node.js/NPM community follows semantic versioning (“semver”). Semantic versioning describes how to manage version changes to a software product. Semver formats the version number using a MAJOR.MINOR.PATCH construct. You should change a MAJOR version when you make incompatible API changes, a MINOR version when you add functionality in a backwards-compatible manner, or a PATCH version when you make backwards-compatible bug fixes.

CommonJS modules

Node.js supports CommonJS modules. These modules enables developers with the ability to organize their code into small files that define specific functionality. This plays a huge role in allowing Javascript developers to build large and scalable applications. In a CommonJS module, anything that is assigned to module.exports can be accessible to another module through invoking the require function. The require function expects a relative or absolute path to the module being imported, like require('./relative/path/to/the/module.js'). CommonJS modules can not be co-dependent, meaning that if module “A” requires module “B” then “B” can not also require “A”.

Test Driven Development

Test driven development (TDD) is a methodology for writing code. It relies on a very short development cycle, which means that it expects developers to create small and testable features. TDD can speed up development time, validate the integrity of new code, and help developers understand their goals. TDD is broken down into three steps - red, green, and refactor.

RED: Make a plan for the code that needs to be written. Write tests that will run your code and check for expected behaviors. At this point, if you run your tests, they should fail (red).

GREEN: Write code to pass the specifications of your tests, without making it perfect. If you succeed, when you run your tests, they should pass (green).

REFACTOR: Refactor your code for speed, memory optimization, and most importantly readability. Your tests should still pass after this step.

Continuous Integration(CI)

is the process of regularly merging individually developed features of code into a shared repository as frequently as they are made. In the most basic setup, a team could simply use git to merge code into a master branch. However more advanced CI patterns can be developed. These patterns can automate static analysis (lining), running unit and integration tests, testing platform support, enforcing code reviews, and much more.

Continuous Delivery(CD)

is the process of deploying software in short cycles by ensuring that software can be deployed at any time. CD pairs very will with advanced CI setups that help ensure the core product is always a stable code base.

Github Actions

Github Actions is a hosted and distributed continuous integration service (CI) that is most often used to build and test software projects hosted on GitHub. Actions are configured by adding a rules file (.yml formatted) in a folder named .github/workspaces in the root directory of the repository. This file specifies the programming language used, the desired building and testing environment and various other parameters. Once you have the setup completed, Github will automatically run your tests on every push and/or pull request. It can (and will) prevent you from merging to a branch (such as master) and hence do a deployment to a production server when your tests are not passing.