I'm not sure if this is possible to fix but I wanted to document this gap:
// From either module or script:
eval('import("./x.mjs")')
// From inside a module:
eval('import.meta')
I didn't fully test new Function/direct/indirect eval but IIRC all three should work. There's some bugs in import.meta on node master but once V8 6.4 lands, it should work with eval.
Yeah, this is super fringe. Found it by accident while trying to trick ESLint into parsing my file w/o turning to the babel parser... :D
Hi @jkrems!
This is known and something we could support, since we can have a compiler and do parse for eval for other things. But I'll close until there's more demand than just poking around at it.
Update:
On second thought, since we're already detecting eval I might as well throw a compile into it.
I'll keep it simple for now and see how it goes.
Thanks for digging into this @jkrems! Can you explain your usage in ESLint a bit more. Is there something we can expand support for to enable use without Babel there?
Can you explain your usage in ESLint a bit more. Is there something we can expand support for to enable use without Babel there?
This is more an inherent "issue" with ESLint itself - it doesn't parse import.meta or import() because they aren't stage 4 yet, at least by default. Me using eval was just a prototyping hack because I was too lazy to bother with properly configuring the parser. :)
Ah ya, I've seen other projects gate to stage 4 too. While I understand it from a project maintainer point of view, as a user it feels a bit rigid. I think rules should be a bit more wiggly to allow for things like dynamic import(), which is supported by tools like webpack, and import.meta, which is a natural extension to the import syntax.
As you can see by my support of dynamic import(), import.meta, object-rest-spread, async generators, and making things "just work", I tend to side with users over maintainer convenience.
@jkrems You can use babel-eslint as parser and add babel-plugin-dynamic-import-node as well as babel-plugin-syntax-dynamic-import to work around the import() issues on eslint.
Patched:
https://github.com/standard-things/esm/commit/5931e96b6f96f54e93ed0de0014ff368c6d7b7a3, https://github.com/standard-things/esm/commit/e7560f61d86b15d39e63e7d1ebcea91f8ba0dce6, https://github.com/standard-things/esm/commit/a9b50ced5759ab7bca493642bd3b579aed59e763, https://github.com/standard-things/esm/commit/d9823ddc536e6f517295cb5b78adf1de0e0a513b, https://github.com/standard-things/esm/commit/b06ec7dd6bccbbae6ac7762298de17ca44622896, https://github.com/standard-things/esm/commit/ea03b259350bba5df8d7a9eca90dd2fa9d17b886, https://github.com/standard-things/esm/commit/2891caa34209f05a639e3bc3bf7a20eb71cd1616, https://github.com/standard-things/esm/commit/67b7eb4df908be41c46a6a62727cad7a13576572, and https://github.com/standard-things/esm/commit/37d26f2e828dda1f229a407a17e22193587a7680.
I'll follow up with Function constructor support as needed.
Most helpful comment
Ah ya, I've seen other projects gate to stage 4 too. While I understand it from a project maintainer point of view, as a user it feels a bit rigid. I think rules should be a bit more wiggly to allow for things like dynamic
import(), which is supported by tools likewebpack, andimport.meta, which is a natural extension to the import syntax.As you can see by my support of dynamic
import(),import.meta, object-rest-spread, async generators, and making things "just work", I tend to side with users over maintainer convenience.