Consider the following function:
function isContainingDirectory(path, callback) {
const directoryName = getDirectoryName(path),
numTotalChecks = 2;
let numChecksDone = 0;
callbackHasBeenCalled = false;
Consider the following function:
function isContainingDirectory(path, callback) {
const directoryName = getDirectoryName(path),
numTotalChecks = 2;
let numChecksDone = 0;
callbackHasBeenCalled = false;
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; | |
}`; |
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
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
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.
Current version (as of 2021-01-28) of Babel's command line program can be installed with:
npm install --global @babel/cli
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
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
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.
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
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
.