EXPORT_ES6 mode import.meta.url is not supported

[k2snowman69]

Issue:
A recent PR resulted in the use of import.meta.url for EXPORT_ES6. However this functionality is currently only at stage 3 (proposal) which means support for this functionality is fairly low which includes eslint, babel, Firefox and Edge all not supporting it currently (all implement at stage 4 or later)

Context:
Looks like there was already a discussion about this and how support isn't quite there yet.
#7137

[VirtualTim]

Whoops, that was my fault. Originally I was using performance.getEntries().slice(-1)[0].name, which is probably more supported (if much uglier). #8306 (comment)

An idea might be to use performance.getEntries().slice(-1)[0].name, and leave a comment to swap this with import.meta.url in the future. But I'm far from a JavaScript expert, so someone else might have a better idea.

[k2snowman69]

Another option is to check for the existence of import and import.meta else back onto the old code base.

[davidyxu]

Just wanted to chime in on this conversation, the project I'm working on recently ran into this issue where import.meta.url isn't available (we tried to polyfill it through .

I think it might make sense for this into an opt-in flag where people who are targeting an environment where import.meta.url is reliably available can use it.

https://github.com/emscripten-core/emscripten/pull/8306/files#diff-ae40e645f84e893ce5d037b5efc53be6R2849
i.e. replacing this part of the code with:

if shared.Settings.EXPORT_ES6 and shared.SETTINGS_EXPORT_USE_IMPORT_META :
        script_url = "import.meta.url"

[k2snowman69]

Wouldn't checking the existence of it also succeed if it's been polyfilled? Meaning less code and settings for the same goal? Or do you mean that there maybe some people who wouldn't want to use import.meta.url even if it's available?

[davidyxu]

If I'm understanding your suggested approach correctly, I think that would end up being more code being delivered to clients since it would need to be a runtime check.

In general I think putting the flexibility into the hands of the emsdk user is better here because there's a lot of variables in the module's running context that will be unknown to emscripten.

For example, some projects might be going through webpack and webworkers, using a loader like the one shown here:
https://github.com/open-wc/open-wc/blob/master/packages/webpack-import-meta-loader/webpack-import-meta-loader.js
Where it'll do a search and replace of import.meta to a small JS object to polyfill it. Now the project will end up with a web worker that is trying to access window in a context where it doesn't exist.

All of these things are workaroundable, but it feels to me like the simplest fix would be to have emscripten default to something reasonable but options to opt-in to more future facing functionality, that way its easy for a user to fix without code changes in emscripten if they run into a weird situation.

[VirtualTim]

Just wanted to chime in on this conversation, the project I'm working on recently ran into this issue where import.meta.url isn't available (we tried to polyfill it through .

Out of curiosity, what did you use as the polyfill? Something that would work in an ES6 Module and web worker?

[benjamind]

We tried using this webpack loader - https://www.npmjs.com/package/@open-wc/webpack-import-meta-loader

Which I believe should work fine for normal main thread usage, but does not function on a webworker. Hence the need to compile to ES6 but also not-use the import.meta.

[kripken]

@VirtualTim

An idea might be to use performance.getEntries().slice(-1)[0].name, and leave a comment to swap this with import.meta.url in the future. But I'm far from a JavaScript expert, so someone else might have a better idea.

That sounds reasonable, since we have multiple reports of people hitting this problem.

[VirtualTim]

Thinking about this again, perhaps it's better to just just import.meta behind both EXPORT_ES6 and USE_PTHREADS, since EXPORT_ES6 + USE_PTHREADS currently rely on dynamic module loading anyway, which only currently works in Chrome with Experimental Web Platform features flag set.

For the people having issues with this, did the old document.currentScript technique work for you? I thought that wasn't supported in an ES6 module.

[davidyxu]

Neither technique really worked for us, we're currently working around it with the SINGLE_FILE flag. The problem with the import.meta.url is that it throws an exception, so the rest of the code can't even evaluate.

It would be great if we could get it working without the SINGLE_FILE flag, the suggested change of performance.getEntries().slice(-1)[0].name would help find the wasm file (although it looks like it makes the assumption that the wasm is served as a sibling to the js glue code).

[kripken]

This sounds fairly urgent to fix since it is a regression - @VirtualTim do you have time to look into it?

[VirtualTim]

Yeah sorry, I've been busy with other stuff.
Taking another look at it performance.getEntries().slice(-1)[0].name doesn't always seem to work (occasionally returns "first-paint"). But I'm sure I could do something smarter with performance.getEntries() to make it work.

I'm seeing if there's any better alternatives, however import.meta actually seems fairly wildly supported:
Chrome 64 (March 2018), Firefox 62 (September 2018), Babel 7 (August 2018), Safari (can't seem to find release notes, but appears to have need added in the beta in October 2017). I couldn't find any info about Edge (maybe it's there now that's it's chromium based?), and I'm assuming that IE doesn't work with anything.

Webpack is missing it, but you can use this plugin to add support.

So what is the minimum environment that I should be targeting?

[k2snowman69]

I think for me personally, the webpack plugin that is referenced along with the fact that rollup already merged in their fix should resolve my initial issue (though still need to test that theory).

However the general question for this project of "what is the minimum environment that I should be targeting?" is still a very important question.

• If you target tc39 stage 3 then there could be features of which have not been implemented by build tools or browsers even (Edge lags behind but hopefully resolved with the chromium update)
• If you target tc39 stage 4 then you don't get to use the very useful fun features
• If you target the latest browser and n-2 versions (common for many websites) you find out that Safari really only publishes new major builds every year and added import.meta.url in Safari 11. Since were currently on Safari 12 and we would back compat all the way to 10 which was released in 2016.

For forward compatibility though, creating a useful way to turn on optional features is great. I have personally come to like typescript's lib option which provides a very detailed but organized solution to turning on future features that aren't currently part of the tc39 stage 4 spec.

[k2snowman69]

Also, if someone comes here and is curious how to get babel@7 to work with the import.meta.url, it's not supported by default, you have to add a plugin @babel/plugin-syntax-import-meta. This is also true for jest since jest uses babel in the background. To fix this for jest, you'll have to add the babel-jest library and the plugin mentioned above and override the default babel settings jest has baked in.

Honestly after testing the fix here... (IMO) I'm having to add a lot of extra packages as work arounds because even though the browsers support this feature, the tooling doesn't.