ugultopu

Consider the following function:

function isContainingDirectory(path, callback) {
  const directoryName = getDirectoryName(path),
        numTotalChecks = 2;

  let numChecksDone = 0;
      callbackHasBeenCalled = false;

ugultopu

Summary

The following type of callbacks:

(err, ...args) => {
  if (err) return callback(err);
  // Rest of the callback code (that is, the "happy path").
}

ugultopu

const parser = require('@babel/parser');
const traverse = require('@babel/traverse');

// console.log('parser is', parser);
// console.log('traverse is', traverse);

const code = `function square(n) {
  return n * n;
}`;

ugultopu

When creating a pull request on an project that you forked, you should rebase the master branch of the original repository on your branch and then create the pull request. Similarly, when the branch of a pull request has become out of date w.r.t the master branch (that is, the default branch), again, you should rebase the default branch of the original repository on your pull request's branch and then force push your branch. So, while you are on your pull request's branch:

git remote add upstream https://github.com/original-owner-of-the-project/project-name
git rebase upstream/master

git push -f

ugultopu

I had a very sneaky bug that I spent a fair bit of time debugging (using console.log initially). When I finally used the real debugger (node inspect my-script.js), I was able to understand where the problem was. The problem was at the following, can you detect the problem?

/**
 * - Create a shallow clone of `object`
 * - Set the prototype of the clone to the prototype of the original object object
 * - Recursively remove _own_ properties of the clone that:
 *   - Are `null` or `undefined`
 *   - Have 0 length
 *   - Have been listed in the `properties` parameter

ugultopu

Summary

npm version 7 and above (also before version 3) installs peer dependencies by default, if they aren't satisfied. (From npm version 3 until 7, users had to manually install the peer dependencies. npm only showed a warning to the users about "unmet peer dependencies" in those versions, but didn't install them by itself). However, Yarn neither installs peer dependencies by default, nor shows a warning about unmet peer dependencies. Hence, when you install a package that has an unmet peer dependency, it will simply not work.

Explanation

Current version (as of 2021-01-28) of Babel's command line program can be installed with:

npm install --global @babel/cli

ugultopu

That is, how to make the text that is sent to a terminal bold, italic, give it colors, etc? The answer is using [ANSI Escape Sequences]. Using the [Control Sequence Introducer] group of ANSI Escape Sequences, we can style the text that appears on a terminal, on the terminals that support ANSI Escape Sequences.

For example, let's say that we want to make a portion of the text that we print bold. We can do it as follows:

// ANSI escape character
const ESC = '\x1B';
// Control Sequence Introducer
const CSI = `${ESC}[`;
// Select Graphic Rendition (SGR) sequences

ugultopu

Disclaimer: This article applies to Babel that runs on Node.js, which is the most common way of running Babel. I didn't check how Babel on a web browser works. The reason I wrote this article is because I didn't notice anywhere on Babel docs that explains what exactly is a Babel plugin. Babel docs mention how a Babel plugin works, what's its purpose, etc. but as far as I can tell, they don't mention what a Babel plugin is.

A Babel plugin is a CommonJS module, whose export is expected by Babel to be a function. That's it. Note that I didn't say "default export", because there is no concept of "default export" in CommonJS. In CommonJS, there is only the module.exports property. This property's value can be any valid JavaScript value. However, Babel expects the value of the module.exports property of a CommonJS module that is designated as a Babel plugin to be a JavaScript function.

How do we know that a Babel plugin is a "CommonJS module"? Can't it be an "ES6 module" as well? No. A Babel plugin is a Com

ugultopu

Summary

Specify the path to your plugin script with a leading ./ or ../. A Babel plugin is a regular CommonJS module, and Babel "processes" what you provide as the "plugin identifier" before converting it to a "module identifier" and loading that CommonJS module using the require function of Node.js.

Per [Node.js module loading rules][Node.js modules API document], a module identifier the does not start with ./ or ../ is searched in node_modules/. Since a plugin that we are currently developing is (most likely) not in a node_modules/ folder, we must specify the path to it with a leading ./ or ../ so that the plugin will not try to be located in a node_modules/ folder, but it will be tried to be located in the relative path that we provide.

Details

As mentioned in ["What is a Babel Plugin?"], a Babel plugin is nothing but regular a CommonJS module, whose value of module.exports is expected to be a function by Babel. Hence, after creating a Babel plugin (i.e after creating a Comm

ugultopu

Because GitHub handles them using JavaScript. Their ID's are prefixed with user-content-. Hence, an ID is like user-content-some-fragment, whereas the fragments are expressed only as some-fragment.