You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently assume AMD as the output module format, something which may or may not change down the line, but is crucial to make things run in a production environment. That said, in development, it may be useful to output different formats. For instance, running tests in a non-browser environment may well be easier with CJS rather than AMD. Additionally, in a development environment, globals may even offer development server capabilities such as reloading modules on the fly, much like figwheel does for ClojureScript.
So the proposal is as such:
Add a --modules option with the following possible values: amd, cjs, umd, global, system
Ignore the --modules option when combined with --production, in which case amd will be used
The text was updated successfully, but these errors were encountered:
Come to think of it, maybe --modules should not be ignored in conjunction with --production, just that it should always default to amd... This would have the interesting effect that ez-build could build itself.
We currently assume AMD as the output module format, something which may or may not change down the line, but is crucial to make things run in a production environment. That said, in development, it may be useful to output different formats. For instance, running tests in a non-browser environment may well be easier with CJS rather than AMD. Additionally, in a development environment, globals may even offer development server capabilities such as reloading modules on the fly, much like figwheel does for ClojureScript.
So the proposal is as such:
--modules
option with the following possible values:amd
,cjs
,umd
,global
,system
--modules
option when combined with--production
, in which caseamd
will be usedThe text was updated successfully, but these errors were encountered: