ModuleLoader / node-es-module-loader

ES Module Loader Node resolution implementation with CJS interop
29 stars 3 forks source link

require is not defined #7

Open shellscape opened 7 years ago

shellscape commented 7 years ago

Given this snippet:

import bodyParser from 'koa-bodyparser';
import Koa from 'koa';

const chalk = require('chalk');

the result when trying to load this module is:

const chalk = require('chalk');
              ^
require is not defined

I understand from this issue https://github.com/ModuleLoader/es-module-loader/issues/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.

guybedford commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.