Konubinix' opinionated web of thoughts

Javascript

Fleeting

engines

deno

only deals with ES module, no CommonJS. Provides a nice, golang go-ish way to load modules using urls.

bun also provides an engine as well as a bundler

nodejs

Node.js is a JavaScript runtime built on the V8 JavaScript engine.

https://nodejs.org/api/documentation.html

hooks

determining module system

  • External reference: https://nodejs.org/api/packages.html#determining-module-system

    Node.js will treat the following as ES modules when passed to node as the initial input, or when referenced by import statements or import() expressions:

    • Files with an .mjs extension.
    • Files with a .js extension when the nearest parent package.json file contains a top-level “type” field with a value of “module”.
    • Strings passed in as an argument to –eval, or piped to node via STDIN, with the flag –input-type=module.

    https://nodejs.org/api/packages.html#determining-module-system

    Node.js will treat as CommonJS all other forms of input, such as .js files where the nearest parent package.json file contains no top-level “type” field, or string input without the flag –input-type.

    https://nodejs.org/api/packages.html#determining-module-system

    Node.js will treat the following as CommonJS when passed to node as the initial input, or when referenced by import statements, import() expressions, or require() expressions:

    • Files with a .cjs extension.
    • Files with a .js extension when the nearest parent package.json file contains a top-level field “type” with a value of “commonjs”.
    • Strings passed in as an argument to –eval or –print, or piped to node via STDIN, with the flag –input-type=commonjs.

    https://nodejs.org/api/packages.html#determining-module-system

modules loaders

  • External reference: https://nodejs.org/api/packages.html#modules-loaders CommonJS module loader:

    • It is fully synchronous.
    • It is responsible for handling require() calls.
    • It is monkey patchable.
    • It supports folders as modules.
    • When resolving a specifier, if no exact match is found, it will try to add extensions (.js, .json, and finally .node) and then attempt to resolve folders as modules.
    • It treats .json as JSON text files.
    • .node files are interpreted as compiled addon modules loaded with process.dlopen().
    • It treats all files that lack .json or .node extensions as JavaScript text files.
    • It cannot be used to load ECMAScript modules (although it is possible to load ECMASCript modules from CommonJS modules). When used to load a JavaScript text file that is not an ECMAScript module, it loads it as a CommonJS module.

    https://nodejs.org/api/packages.html#modules-loaders

ECMAScript module loader:

  • It is asynchronous.
  • It is responsible for handling import statements and import() expressions.
  • It is not monkey patchable, can be customized using loader hooks.
  • It does not support folders as modules, directory indexes (e.g. ‘./startup/index.js’) must be fully specified.
  • It does no extension searching. A file extension must be provided when the specifier is a relative or absolute file URL.
  • It can load JSON modules, but an import assertion is required.
  • It accepts only .js, .mjs, and .cjs extensions for JavaScript text files.
  • It can be used to load JavaScript CommonJS modules. Such modules are passed through the cjs-module-lexer to try to identify named exports, which are available if they can be determined through static analysis. Imported CommonJS modules have their URLs converted to absolute paths and are then loaded via the CommonJS module loader.

https://nodejs.org/api/packages.html#modules-loaders

package.json “type” value of “module” tells Node.js to interpret .js files within that package as using ES module syntax

https://nodejs.org/api/packages.html#modules-loaders

If the nearest parent package.json lacks a “type” field, or contains “type”: “commonjs”, .js files are treated as CommonJS.

https://nodejs.org/api/packages.html#type

  • Files ending with .mjs are always loaded as ES modules regardless of the nearest parent package.json.
  • Files ending with .cjs are always loaded as CommonJS regardless of the nearest parent package.json.

https://nodejs.org/api/packages.html#modules-loaders

package

package is a folder tree described by a package.json file

https://nodejs.org/api/packages.html#determining-module-system

browser

debug

debug android web app with chrome

chrome://inspect/#devices

Console Utilities API reference
monitorEvents to find out what events are available

monitorEvents(object [, events]) When one of the specified events occurs on the specified object, the Event object is logged to the console. You can specify a single event to monitor, an array of events, or one of the generic events “types” mapped to a predefined collection of events. See examples below.

https://developer.chrome.com/docs/devtools/console/utilities/#monitorEvents-function

datatypes

number

A number literal like 37 in JavaScript code is a floating-point value, not an integer. There is no separate integer type in common everyday use. (JavaScript also has a BigInt type, but it’s not designed to replace Number for everyday uses. 37 is still a number, not a BigInt.)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number

fatigue

bundlers

bun

webpack

target

  • External reference: https://webpack.js.org/configuration/target/

    target string [string] false

    Instructs webpack to generate runtime code for a specific environment. Note that webpack runtime code is not the same as the user code you write, you should transpile those code with transpilers like Babel if you want to target specific environments, e.g, you have arrow functions in source code and want to run the bundled code in ES5 environments. Webpack won’t transpile them automatically with a target configured

    https://webpack.js.org/configuration/target/

multiple targets

you can create an isomorphic library by bundling two separate configurations:

webpack.config.js

const path = require(‘path’); const serverConfig = { target: ’node’, output: { path: path.resolve(__dirname, ‘dist’), filename: ’lib.node.js’, }, //… };

const clientConfig = { target: ‘web’, // <=== can be omitted as default is ‘web’ output: { path: path.resolve(__dirname, ‘dist’), filename: ’lib.js’, }, //… };

module.exports = [serverConfig, clientConfig]; The example above will create a lib.js and lib.node.js file in your dist folder.

https://webpack.js.org/concepts/targets/

output.globalObject

Are ‘Arrow Functions’ and ‘Functions’ equivalent / interchangeable?

Arrow functions don’t have their own this or arguments binding. Instead, those identifiers are resolved in the lexical scope like any other variable. That means that inside an arrow function, this and arguments refer to the values of this and arguments in the environment the arrow function is defined in (i.e. “outside” the arrow function

https://stackoverflow.com/questions/34361379/are-arrow-functions-and-functions-equivalent-interchangeable

ES2015 distinguishes between functions that are callable and functions that are constructable. If a function is constructable, it can be called with new, i.e. new User(). If a function is callable, it can be called without new (i.e. normal function call). Functions created through function declarations / expressions are both constructable and callable. Arrow functions (and methods) are only callable. class constructors are only constructable. If you are trying to call a non-callable function or to construct a non-constructable function, you will get a runtime error

https://stackoverflow.com/questions/34361379/are-arrow-functions-and-functions-equivalent-interchangeable

inheritance and the prototype chain

When trying to access a property of an object, the property will not only be sought on the object but on the prototype of the object, the prototype of the prototype, and so on until either a property with a matching name is found or the end of the prototype chain is reached.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

notation someObject.[Prototype]] is used to designate the prototype of someObject

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

[Prototype]] internal slot can be accessed and modified with the Object.getPrototypeOf() and Object.setPrototypeOf() functions respectively

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

is equivalent to the JavaScript accessor proto which is non-standard but de-facto implemented by many JavaScript engines

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

Notes linking here