@mikesherov @brianleroux There are already two parsing goals (FunctionBody for CJS modules and Script for everything else)
-
-
@mikesherov@brianleroux .js has always meant "contextually processed JS code"; current ecosystem uses .js for standard modules too 3/3 -
@wycats@mikesherov@brianleroux current ecosystems target systems that do not support interop. this is a key difference, only one mode -
@bradleymeck@mikesherov@brianleroux not true of <script type=module>, TypeScript or Babel. Not true of Ember CLI. -
@wycats@mikesherov@brianleroux Node is CJS, browser <script> is Script, <script type=module> is Module. only compile to one/UMD -
@wycats@mikesherov@brianleroux an example is using babel for CJS from ES; loaded as CJS in node. Interop is more than compile targets -
@wycats@mikesherov@brianleroux we don't really have an existing host env that supports 2 native level module systems yet -
@bradleymeck@mikesherov@brianleroux ember-cli w/ ember-browserify is one such environment. 1/ -
@bradleymeck@mikesherov@brianleroux Right now we use import 'npm:*' due to the primacy of standard modules, but working to eliminate 2/2 - 11 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.