SMotaal

Forks

guybedford/node/tree/irp-implementation

Setup

# clone
git clone https://github.com/guybedford/node.git --branch irp-implementation --single-branch node-esm

SMotaal

source
https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal/blob/eb77f14d68b6502a82837fff9f1be184148be5ee/README.md

File Specifier Resolution in Node.js

Contributors: Geoffrey Booth (@GeoffreyBooth), John-David Dalton (@jdalton), Jan Krems (@jkrems), Guy Bedford (@guybedford), Saleh Abdel Motaal (@SMotaal), Bradley Meck (@bmeck)

Motivating Examples

SMotaal

Specifiers

I have been trying to find a good way to paraphrase intuitive concerns regarding scheme-less specifiers and I think that while import: is different from other ideas proposed for somewhat related purposes, it may be coming from similar but more tangible consideration.

Yesterday I did a little experiment with URL in node, Chrome, and Safari , and Firefox. My general thought is that new URL(x, y) is a resolution formula that follows closest to the web standards so my assumption is that it pairs well with the whatwg expectations on specifiers.

The bottom line is that constructing scheme-less specifiers that depend on scheme-less referrers is not possible, and the hack used just to get through the list of valid specifiers was to resolve the referrer against file://y:/ which is not a proposed solution by all means.

Given the importance of specifier resolution (ie x -> y = z) I am

SMotaal

module.exports = 'cjs';

SMotaal

Fragma (concept)

Okay, concept means messy and probably requires flags on nightly or the likes, agreed? Just don't expect this to be more than what it is!

Live Demos

throttle — renders n instances of a perpetually changing element

https://smotaal.github.io/experimental/fragma/alpha/throttle#n

• #100

SMotaal

Markie

Along with the many disruptive trends in code editors and text documents (Markdown) in general (Markup) comes the inevitable question, Is it time for a new take on the various design patterns and implementation strategies used to work with source text?

Distruption

Code Editors

While there are many JavaScript code editor implementations out there, you can almost divide them down by eras, for instance, ones predating GitHub's overwhelming effect on the adoption of Markdown, ones during the height of JQuery… etc. But regardless of eras, the way those editors model markup, while very much full of a lot of originality and creativity, they often seem to pivot around variants of similar and familiar patterns. One clear observation that begs pointing out, since most (if not all) value features in any implementation are often coupled to the specific variations of the markup model, adopting new and distruptive ideas often times leads to completely new implementations (some still call those ve

SMotaal

Option	Default	Description
validateOptions	false	crashes if mis-typed JSC options were passed to the VM
dumpOptions	0	dumps JSC options (0 = None, 1 = Overridden only, 2 = All, 3 = Verbose)
configFile	""	file to configure JSC options and logging location
useLLInt	true	allows the LLINT to be used if true
useJIT	true	allows the executable pages to be allocated for JIT and thunks if true
useBaselineJIT	true	allows the baseline JIT to be used if true
useDFGJIT	true	allows the DFG JIT to be used if true
useRegExpJIT	true	allows the RegExp JIT to be used if true

SMotaal

Terminology: Contribution

Definitions are authored in reStructuredText as it offers the necessary shorthand syntax and supports a fair subset of common Markdown syntaxes which minimizes both conversion and learning burdens for contributors.

SMotaal

Header 1

Subtitle

Example text.

Table of Contents

SMotaal

This prototype simply relies on async execution to walk the module graph and uses the platform to create either a ModuleWrap in node (when possible) or a blob which is used to determine the actual specifier to use for each link outwards.

A given limitation is that circular references will result in deadlock.