Support multiple runtimes

[ochafik]

When #310 is done, we'll be able to target different module systems. The runtime files will need to match those targets, and more generally we may want a runtime built with the same flags as the user code.

An option we discussed is to checkin the code for a couple of "predefined" major runtimes (e.g. one with ES6 modules, another with our current module system, etc), but we may also need a way to serialize the codegen options and lazily create a adhoc version of the runtime with those options.

[ochafik]

I suggest we ship the following runtimes:

• Legacy (current, no destructuring)
• ES6 modules (no types): can be consumed today by tools like rollup
• Node modules (no types): will eventually be dropped when node supports ES6 modules
• TypeScript (Closure workarounds + ES6 modules + TS types + maybe non-reified generics?)

This should allow us to cover most of the interesting cases highlighted in this doc.

We should bundle the generated SDK sources as resources, so as to cover the other cases on the fly and to allow DDC to perform "whole-world" tree-shaking.

Proposed layout:

• lib/runtime/default (./dart/_runtime.js, ./dart_library.js...)
• lib/runtime/es6 (./dart/_runtime.js...)
• lib/runtime/node (./dart/_runtime.js...)
• lib/runtime/typescript (./dart/_runtime.ts...)
• lib/runtime/sdk_sources (./version, ./lib/core/bool.dart...)

[jmesserly]

Nice writeup :)

Legacy (current, no destructuring)

I hope we can get rid of "legacy" in favor of one of the browser-friendly JS module patterns.

I like the "proposed layout" ... here's a few small tweaks:

• lib/runtime/browser (./dart/_runtime.js, ./dart_library.js...)
• lib/runtime/es6 (./dart/_runtime.js...)
• lib/runtime/node (./dart/_runtime.js...)
• lib/runtime/typescript (./dart/_runtime.ts...)
• lib/sdk (./version, ./lib/core/bool.dart...)

the idea is "lib/runtime" for our JS pre-compiled files (we may be able to get rid of this at some point, and use caching instead.) "lib/sdk" is for the SDK sources.

Aside, I'm starting to wonder if we'll want to move those into https://github.com/dart-lang/sdk. Some work to do on merging first, though.

[jmesserly]

BTW, I presume "lib/sdk" is the current "tool/generated_sdk", not "tool/input_sdk", which is different.

To use "tool/input_sdk" we'd have to teach DDC how to handle _patch files. Which is doable, but not something that DDC currently understands (see tool/patch_sdk).

[ochafik]

Yes, shortened tool/generated_sdk but maybe best to keep it fully explicit.

[jmesserly]

FYI, I'm going to take a look at this.

DDC almost doesn't care at all what module format you use until the very end. I think it's doable to have it emit the SDK in all formats. Shouldn't add much (if any) to the build time.

[jmesserly]

Fixed :)