Proposal: import.meta.urlBase

[guybedford]

Many use cases around import.meta.url are based on relative loading of sibling paths to import.meta.url.

These naturally end up quite unwieldy, for example loading a worker in the same folder:

new Worker(import.meta.url + '/../worker.js', { type: 'module' });

or even:

new Worker(new URL('./worker.js', import.meta.url).href, { type: 'module' });

Just like Node.js supports both __filename and __dirname, if we had cross-platform support for import.meta.urlBase (name to be bikeshed further), then this could be simplified to:

new Worker(`import.meta.urlBase + '/worker.js', { type: 'module' });

This could help in simplifying conventions around these sibling fetch cases.

[domenic]

I don't think encouraging URL resolution via the + operator is a direction we want to encourage, at least on the web.

[jkrems]

Would it be enough if there was an equivalent of import.meta.resolve('./worker.js')? That would also support getting URLs from import maps (import.meta.resolve('image-processor/worker')).

[domenic]

Yep, I think that's a good direction. However it's unclear whether we can make a sync import.meta.resolve() given import maps with fallbacks :-/. WICG/import-maps#79

Hoping that making more progress on the import maps spec (as opposed to explainer) will make the issues there clearer and unblock progress.

[jkrems]

Ah, yes. Forgot about that part. :(

[guybedford]

@domenic could you perhaps elaborate on why you find issue with string concatenation relative to a parent?

[domenic]

URL parsing is complicated and any attempts to replace it with just string concatenation are bug farms. For example, depending on whether import.meta.url / import.meta.baseURL ends with a slash or a dot or various other special characters, you would get unexpected results.

[guybedford]

All APIs that accept URLs will do their own URL parse. Given that import.meta.url / import.meta.baseURL are already known to be valid URLs, we know for a fact that the URL parse will at least get as far as that part of the string concatenation.

If import.meta.baseURL does not end in /, then yes, it will be possible to construct URLs that combine with the directory name, but I don't think that would surprise anyone.

If users start the concatenation part with ../ then they can backtrack below the import.meta.url / import.meta.baseURL, yes, but again that seems a feature not a bug.

What other complexities are there?

[MylesBorins]

Closing as proposal is now stage 4