you would need to introduce a new language-syntax that hints delimited module-scope, e.g.
```js /* * es-module.rollup.js * * example rolling-up es-modules with [hypothetical] pragma * "use module_scope xxx"; * which would be web-compat and minifier-friendly */ "use module_scope ./aa.js"; // foo is scoped inside module_scope ./aa.js var foo = ... ... "use module_scope ./bb.js"; // foo is scoped inside module_scope ./bb.js var foo = ... ... ``` i'll be honest. i'm not really proposing this language-syntax in good-faith, as javascript is already chock-full of confusing-features that are distracting/harmful to UX-workflow programming. i'm mainly criticizing tc39 for their design-decision pushing through es-modules, and how disruptive it is to operationalize (natively, w/o transpiling) in production-systems. web-development could've stayed simpler if the committee had done absolutely nothing. people would've continued using es5-style rollups (w/ yui/amdjs-like module-loaders), and devop-folks wouldn't be forced to deal with import-maps and http2-push to solve a problem that shouldn't have existed. On Sun, Jun 2, 2019 at 9:25 PM guest271314 <[email protected]> wrote: > > but that requires coordination among modules, which is not always > possible. the idea is to inline/rollup es-modules that may not have come > from same developers (and whom are unaware their es-modules collide w/ > others when rolled-up). > > How do you intend to know the names of the identifiers to import without > "coordination" and check for duplicate identifier names and duplicate > exports? >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
