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
{{ message }}
This repository was archived by the owner on Jul 13, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Jul 13, 2020. It is now read-only.
const chalk = require('chalk');
^
require is not defined
I understand from this issue ModuleLoader/es-module-loader#427 that the loader has made the assumption that the user only wants ES6 module support and not interoperability with require for CommonJS modules.
While that is a perfectly good and reasonable argument for the es-module-loader module, the node-esml binary would imply by README description and name that there is a measure of interoperability with Node's current and default loader mechanisms. This would follow use of babel in node server-side code in which we're able to use require within ES6 modules.
The 'sync' nature of require can be duplicated using async/await patterns on the dynamic import, however that can only be used on node > 7 with harmony flags, or node 7.6 - both of which are not yet options for a large chunk of developers due to restrictions in the workplace.
I'd like to at the least point out this limitation and the perception that it may be interpreted as a bug by folks not intimately familiar with loaders and/or es-module-loader. And I'd like to propose the interoperability with default node require support as a new feature.
Or at the least, an updated README with a solution to provide support for require. If I'm missing something where require-like capabilities exist, such as the ability to load JSON files as objects, then please do consider adding those to the README, as I haven't found a suitable workaround as simplistic as requiring the file.
Mixing require and ES module syntax is not something that Node itself will be doing, so the goal of this project is to align with how things will work in future. Yes this workflow isn't quite ready for prime time yet, but it gets us close to it. Encouraging the right patterns and correctness is the goal here over trying to provide the very best workflow for the existing state of things today.
Interesting, and thanks for addressing so quickly. I've been trying to stay ahead on the developments around that, but I clearly missed some discussion - any chance you have references you could share about that no-intermixing-module-types?
There is currently no spec for the registry API methods like System.delete. This project can't do anything until there is at least a candidate spec. This is the sort of thing that should be discussed at the spec-level first.
Activity
guybedford commentedon Mar 16, 2017
Mixing require and ES module syntax is not something that Node itself will be doing, so the goal of this project is to align with how things will work in future. Yes this workflow isn't quite ready for prime time yet, but it gets us close to it. Encouraging the right patterns and correctness is the goal here over trying to provide the very best workflow for the existing state of things today.
shellscape commentedon Mar 16, 2017
Interesting, and thanks for addressing so quickly. I've been trying to stay ahead on the developments around that, but I clearly missed some discussion - any chance you have references you could share about that no-intermixing-module-types?
chyzwar commentedon May 19, 2017
I wanted to use require to get synchronous code splitting. import() would make my constructor async.
Would be possible to add something like System.delete from systemjs ?
Do you know if spec for ES modules provide a way to unload module from registry?
guybedford commentedon May 20, 2017
There is currently no spec for the registry API methods like
System.delete. This project can't do anything until there is at least a candidate spec. This is the sort of thing that should be discussed at the spec-level first.chyzwar commentedon May 20, 2017
yeah, this is what I was guessing.
Problem is that import() being asyc in browser make sense but not so much in node.
I was thinking about hacking around with System.delete.