Polyfilling require

[evenstensberg]

When importing a js file, of which, has top-level require in it, is there a way to polyfill those to use imports or something similar in order to get the script loaded?

Might be related to #2054 but it's not dynamic

[ry]

For common JS this should be possible - you just readFileSync the file and eval it (in some manor). However for loading ES modules, we need the #2054.

[evenstensberg]

I traced this back to #1938 but it's another issue. What's the current status?

[benjamingr]

When importing a js file, of which, has top-level require in it, is there a way to polyfill those to use imports or something similar in order to get the script loaded?

You can run rollup or another bundler on that file first and get an output without top level require - it's what I've done with Deno before when trying to "share code" between projects.

[kitsonk]

I think properly polyfilling require() would be challenging, and top level requires are essentially dynamic imports and would be a whole challenge because of the lack of top level await and the whole flow of the loading. Essentially you would be building a whole loader within a loader.

Both @benjamingr's solution and #2114 is a potential solution. #2114 would be the way that I think we should support it long term out of the box.

[rsp]

@kitsonk I think it's even more complicated than that. With dynamic imports and top level await you wouldn't be able to implement require because it is synchronous and returns what was actually in module.exports immediately after the module wrapper was executed, so probably readFileSync+eval (plus caching) would be the only way to preserve the require() semantics.

[benjamingr]

@rsp it is significantly simpler to use a module bundler (like webpack, browserify or parcel) to transpile all the requires for you (and deal with the readFile and order) and then do a single dynamic import.

[Mouvedia]

because of the lack of top level await

@kitsonk https://github.com/tc39/proposal-top-level-await

[Fenzland]

Too far away from the standard is not a good idea. ES Modules is good enough.
What we need is not to run node modules in deno but to convert node modules into ES modules.
Something like this will help:
https://github.com/pikapkg/builders/tree/master/packages/plugin-build-deno/

[bartlomieju]

Recently #3380 landed, does it resolve the issue?

[kevinkassimo]

@bartlomieju I agree this could be closed. We might want to open another issue tracking std/node polyfill progress though, but anyways that is a different problem.

Likely the polyfill issue can also be treated as Good First Issues (I believe some of them should not be too complicated)