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
| ( | |
| ( | |
| 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 | |
| }) |
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.
| .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: "" |
Now that Electron has hit Chrome's 60s we can have proper module support. But of course, the standard (for very good reasons) prevents loading modules from file: and it makes sense for both Electron and NW.js to adhere to the statusquo.
So if you were really excited and this bums you, don't worry, you are in for awesome things.
The future Electron eco-system offers two options for native ES modules:
-
Custom Electron protocol via Chromium's module loading subsystem
-
Custom NodeJS loaders via Node's module loading subsystem recommended
This is a first draft for a proposal for adding a new dimension to the current ECMAScript module architecture that would make it possible to fulfill platform dependent behaviours for common and non-common requirements without breaking the established compliance criteria. This is not yet a formal proposal.
In the default case of resolving an external dependency (which translates into bindings across two or more linked ES modules) the existing standards are technically sufficient and can only improve by increased adoption and natural progression. However, when it is necessary to either import from or respond to a specific platform, the current standards can be improved upon, which is the topic of several proposals, and is the main focus of this proposal.
Potential Use Cases
// Module-specific
| * { | |
| font-family: sans-serif; | |
| } |
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.