SMotaal

A simple TypeScript loader using NodeJS 9+ declarative loader API

Purpose

This loader is intended to show very quickly how to use the proposed NodeJS 9.0.0 loader API to be able to compile TypeScript files on demand. It is not a stable solution in any way.

Using Node 9+ Loader

SMotaal

(
  (
    str, 
    c = `${str}`.codePointAt(0), 
    p = 0x10000, q = 0x400, r = 0xD800, s = 0xDC00, 
    h = ~~((c-p) / q) + r, l = (c - p) % q + s
  ) => ({
    h, l, 
    c1: c, c2: (h - r) * q + l - s + p 
  })

SMotaal

This gist shows a living realworld example of how a complex NodeJS single-file module can be written in both JS and MJS with the bulk of the files being identical and imports and exports hoisted together. This is done to promote consistency by reducing the task of code updates to a simple copy/paste between the files if transpilaing is not possible.

SMotaal

.markdown-body {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
  font-size: 16px;
  line-height: 1.5;
  word-wrap: break-word
}

.markdown-body::before {
  display: table;
  content: ""

SMotaal

Rational

The TypeScript 2.0-typescript branch seems to be lagging and isolated, with all components having 2.0-preview branches yet the 2.0-typescript README has not even been changed from the 2.0-preview text. Until a proper Polymer/TypeScript workflow is recommended and supported by the Polymer team, the basic idea is to maximize on the use of the essential features that TypeScript offers and not invest too much into hard-core features that require the workflow to be tightly coupled with late-bound transpilation of complex TypeScript projects (with modules / loaders). Another thing to address is how Hydrolysis fails to analyze and iron-component-page fails to document TypeScript-based components, not making good use of the elegant property declarations and decorators used in TypeScript. For now, a temporary workaround is needed to ensure that properties are defined and documented with proper types and default values, but the workaround needs to be easily replaceable once we have better Polymer/TypeScript

SMotaal

* {
  font-family: sans-serif;
}

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.

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

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

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