nodejs on Much Ado About IT

What JavaScript versions are there and how do they map to Node.JS versions?

Julian Knight — Fri, 04 Jan 2019 20:03:59 +0000

There are now far too many versions of JavaScript. Worse, there are several ways to refer to a JavaScript version. Then we have Node.JS which has its own versioning. This post tries to summarise it all.

This is just a summary for my own reference. See References below for more details.

Please let me know if there are any errors. I will update the table periodically.

ECMA-262 Version	ECMAScript Year Version	Publish Date	Node.JS Version
5	N/A	2009-12
6	ES2015	2015-06	6.5.0+
7	ES2016	2016-06	7.0.0+
8	ES2017	2017-06	8.10.0+
9	ES2018	2018-06	10.0.0+

Notes:

Versions of Node.JS prior to those shown are likely to support some features of newer JS versions. The versions shown are those that support virtually all of the features.
Some JavaScript features may not be implemented in Node.JS.
Node uses the V8 JavaScript engine. Also used by the chromium browser (which underpins Vivaldi, Google Chrome, Opera and many others. Soon to be used by Microsoft Edge as well).

References

Wikipedia ECMAScript Article
Kangax’s JavaScript Compatability Table
Node Green - Maps Node versions to JavaScript versions and shows what is supported in each version. Uses Kangax’s table.
Mozilla Developer Network (MDN) - Details each aspect of JavaScript as a reference, each page has a compatibility table showing browsers support. Uses Kangax’s table.

Download a GitHub Repository using Node.JS

Julian Knight — Sun, 30 Dec 2018 22:03:07 +0000

Downloading a repository from GitHub using Node.JS should be really easy. But it isn't! This KB post reminds us of the tricks required.

We have to be careful with the source URL names when working with GitHub as the URL’s generally exposed on the web interface are not the actual URL’s. The Node.JS http/https get() functions don’t handle redirections well.

#!/usr/bin/env node
'use strict'

/**
 * Install the Node-RED alternate installation template
 *
 * Author: Julian Knight (Totally Information), Jan. 2019
 * License: MIT
 */

const fs = require('fs')
const https = require('https')

function download(url, dest, cb) {
 const file = fs.createWriteStream(dest);
 const request = https.get(url, function (response) {
 response.pipe(file);
 file.on('finish', function () {
 file.close(cb); // close() is async, call cb after close completes.
 });
 }).on('error', function (err) { // Handle errors
 fs.unlink(dest); // Delete the file async. (But we don't check the result)
 if (cb) cb(err.message);
 });
};

// Download latest archive from GitHub to temp folder
const dest = './alternate-node-red-installer.zip'
const url = 'https://codeload.github.com/TotallyInformation/alternate-node-red-installer/zip/master'
download(url, dest, function(){
 console.log('Done')
})

Obviously, it would be better to add proper error traps and messaging.

GitHub URL’s

As mentioned, most of the exposed GitHub URL’s actually redirect which upsets Node’s built-in get functions. The downside of using the direct URL’s is that they may change format from time-to-time. If you can, use a 3rd-party library such as request which handles http vs https and redirects without additional programming.

The format for the actual repository archives (in zipped form) is:

https://codeload.github.com/<userOrOrgName>/<repoName>/zip/<branch>

Where: <branch> is either ‘master’ or a git tag ID (e.g. ‘v1.2.3’) or other git branch ID.

For an individual file from the repository, use:

raw.githubusercontent.com/<userOrOrgName>/<repository>/<branch>/<filename>

https://raw.githubusercontent.com/TotallyInformation/alternate-node-red-installer/

References

Using npm configuration environment variables in package.json

Julian Knight — Sun, 30 Dec 2018 22:03:07 +0000

npm automatically makes parts of your package.json file available as environment variables. This can be useful when using npm as a run script service.

npm exposes all of the entries in package.json as environment variables so that any script specified in the scripts section can make use of them.

In the example below we can see both the advantage and the weakness of the approach.

The advantage is that we can pass things like the module version number direct to another command.

The weakness is that the consumption of environment variables is different depending on the operating system in use.

Every property in package.json is exposed this way, simply prefix with npm_package_ and replace subscripts (e.g. scripts.patch) with an underscore (e.g. npm_package_scripts_patch).

Example package.json

We can use this for reference

{
 "name": "Config Example",
 "version": "1.2.3",
 "description": "Using config variables in package.json",
 "author": "Max Headroom",
 "scripts": {
 "patch": "npm version patch -m \"Patch version bump to %s\" ",
 "minor": "npm version minor -m \"Minor version bump to %s\" ",
 "major": "npm version major -m \"Major version bump to %s\"",

 "postinstall": "node ./postinstall.js",

 "win-tag": "git tag -a v%npm_package_version% -m \"Release v%npm_package_version%\"; git push origin --tags",
 "tag": "git tag -a v$npm_package_version -m \"Release v$npm_package_version\" && git push origin --tags"
 },
 "devDependencies": {
 "eslint": "^1.10.3",
 }
}

References

Using config variables in package.json

Node.JS and JavaScript

Julian Knight — Sun, 30 Dec 2018 21:58:14 +0000

Node.JS allows JavaScript to be used as a server-side (back-end) programming language.

References

Knowledgebase Articles

Creating GitHub Releases from git Tags

Julian Knight — Sun, 30 Dec 2018 21:23:20 +0000

The workflow for updating version numbers and doing git/GitHub/npm releases is far too complex to easily remember when you aren't doing it very often. This post is a reminder of the various steps.

Just a quick reminder for myself mainly.

GitHub will automatically create a release from a git tag. Having had a request for this from an issue with node-red-contrib-uibuilder, I decided that I’d better look into how to do it.

Why is everything harder than it should be!? Anyway, here is the raw workflow for committing changes to a git managed repository of code, creating a tag, pushing both master and the tag to GitHub and then publishing to npm.

# This could be minor or major instead of patch, it updates package.js
npm npm version patch -m "Patch version bump to %s"
# We might want to stage instead of committing everything at once
git commit -m "Commit message"
git push
# Create a tag to match the npm version
git tag -a v1.4.1 -m "my version 1.4.1"
git push origin --tags
# Publish to npm
npm publish

Of course, the commit and push are easier done direct from VScode.

It is annoying that I can’t link the tag to the npm version.

References

git docs 2.6 Git Basics - Tagging