... | @@ -2,7 +2,7 @@ |
... | @@ -2,7 +2,7 @@ |
|
|
|
|
|
## Using modules
|
|
## Using modules
|
|
|
|
|
|
At the moment sweet.js supports a primitive form of module support with the `--module` flag. This flag concatenates its arguments together, loads any macros it finds, and makes those macros available to the file being compiled.
|
|
At the moment sweet.js supports a primitive form of module support with the `--module` flag.
|
|
|
|
|
|
For example, if you have a file `macros.js` that defines the `m` macro:
|
|
For example, if you have a file `macros.js` that defines the `m` macro:
|
|
|
|
|
... | @@ -31,7 +31,5 @@ The `--module` flag uses the node path to look up the module file so you can pub |
... | @@ -31,7 +31,5 @@ The `--module` flag uses the node path to look up the module file so you can pub |
|
|
|
|
|
## Limitations
|
|
## Limitations
|
|
|
|
|
|
All module files passed to `--module` are concatenated together before being loaded. This means that there is a potential for macros to clash if you try to define the same macro name in two different files. Though there are cases where you might want this behavior, see the discussion [here](https://github.com/mozilla/sweet.js/issues/145).
|
|
|
|
|
|
|
|
The biggest limitation with the current approach is that you can't arbitrarily interleave importing compile-time values (macros) and run-time values (functions). This will eventually be handled with support for "proper" modules (issue #43).
|
|
The biggest limitation with the current approach is that you can't arbitrarily interleave importing compile-time values (macros) and run-time values (functions). This will eventually be handled with support for "proper" modules (issue #43).
|
|
|
|
|