Skip to content
GitLab

ES6 module integration

Closed Tim Disney requested to merge es6-modules into master

First stab. Very much work in progress but you can (sort of) import compiletime code (macros) and import runtime code for use in macros.

Lots more to do:

  • test coverage
  • more correct import and export syntax
  • better registering of import statements
  • import for templates and arbitrary phases
  • integrate into sjs (it only runs via grunt single atm)

Some design questions that still need to be hashed out:

npm integration

I know @natefaubion has thought a lot about this but basically there's a question of when should we actually expand module from an import. Since lot's of modules won't have compiletime exports we could avoid the expense of expansion for the "common" case when you just want to import runtime code (either for use in a macro body or otherwise).

There's a few obvious ways of doing this:

  1. special import forms signaling your intention/belief about the compiletime status of the imported names
  2. special folder to place source that includes compiletime values (say "macros/")
  3. file/folder pattern in package.json to signify which source files might contain compiletime values

Option 1 is not good because the user of a library shouldn't know how a form is implemented to use it.

Options 2 and 3 bug me because they both rely on macro package authors to know about this (what is at the end of the day) optimization detail.

Ah! As I was typing this out I thought of a fourth option. Use a pragma at the beginning of all sweet.js sources. This makes it easy to determine if the code might need to be expanded. I think we want to do this anyway as a way of following Racket's tower of languages one day:

#lang "js"

// ...

Eventually we can make this tie into readtables and all the custom language stuff.

what to compile for runtime import?

After we expand all the macros away what should we do with the runtime import? Options:

  1. do nothing, import is only for macros. have authors write their own CJS/AMD require statements
  2. emit node require statements
  3. do everything es6-module-transpiler does
  4. leave imports and use es6-module-transpiler as a backend

I think 4 is the best. Not sure if escodegen supports import and export yet so might need to get that working first. Perhaps 1 to begin with and 4 as the end goal?