Support import.meta.url #2164

guybedford · 2018-04-27T17:06:39Z

This property is already supported in both browsers and NodeJS under --experimental-modules.

This implements import.meta.url under the exporimentalDynamicImport option (both on the import reserved identifier!).

The rewriting is designed to be as flexible as possible for all output formats, and through using the global URL, we can remain pretty spec compliant as well.

In the process I refactored NodeTypes to be inlined as strings in the build, which reduces the build size of Rollup. The issue with the types here is that this requires distinguishing between uses of NodeType for a type and for an actual string. So I duplicated these as NodeType.tMemberExpression for the TypeScript type and NodeType.MemberExpression for the JS string. This then allows tree-shaking the unused literals in the output build, reducing build size by a couple of KB.

I also inlined the dynamic import mechanism code a little too, removing some of the logic from Chunk.ts.

Example:

console.log(import.meta.url);

// -> es:
console.log(import.meta.url);
// -> cjs:
console.log(new (typeof URL !== 'undefined' ? URL : require('url').URL)('file:' + __filename).href)
// -> system:
console.log(module.meta.url);
// -> global:
console.log((typeof document !== 'undefined' ? document.currentScript && document.currentScript.src || location.href : new URL('file:' + __filename).href));

justinfagnani · 2018-05-03T06:05:56Z

@guybedford Does this transform preserve the URL of the original module, rather than return the URL of the bundle?

lukastaegert

Looks good, just some minor points

MetaProperty should be a class
Maybe there should be more alignment between the UMD and AMD cases

lukastaegert · 2018-05-03T05:33:16Z

src/ast/nodes/MetaProperty.ts

+	return node.type === NodeType.MetaProperty;
+}
+
+export default interface MetaProperty extends Node {


This should probably be a real AST node class instead of an interface as otherwise, it will never be tree-shaken (as internally, it will be an UnknownNode).

Sure. Does this mean that MetaProperty nodes haven't been treeshakable until now though?

Yes, that's what it means. Which is something they share with spread elements. Though the latter are very hard to get right due to the complex hidden mechanics.

lukastaegert · 2018-05-03T05:38:59Z

src/ast/nodes/MemberExpression.ts

 				storeName: true,
 				contentOnly: true
 			});
+		} else if (isMetaProperty(this.object) && this.object.meta.name === 'import') {


If MetaProperty is a class, this can become an instanceof check

Another advantage would be that we could move the meta logic to the meta class and thus keep the member expression a little cleaner (i.e. even though the overwriting needs to happen in the member expression, the code that is used for overwriting could be taken from the meta property or from an import in the same file).

lukastaegert · 2018-05-03T06:00:44Z

src/ast/nodes/Import.ts

+	umd: undefined,
+	iife: undefined
+};
+


I think moving it here makes a lot more sense 👍

lukastaegert · 2018-05-03T06:03:51Z

src/ast/nodes/MemberExpression.ts

+	cjs: `new (typeof URL !== 'undefined' ? URL : require('url').URL)('file:' + __filename).href`,
+	iife: globalImportMetaUrlMechanism,
+	umd: globalImportMetaUrlMechanism
+};


My assumption was that it should be possible to switch an AMD module for a UMD modules without changed functionality which does not seem to be the case here. Maybe it is possible to make these two cases more similar in case an AMD loader is used?

lukastaegert · 2018-05-03T06:06:41Z

src/ast/nodes/NodeType.ts

+export const VariableDeclarator = 'VariableDeclarator';
+export const VariableDeclaration = 'VariableDeclaration';
+export const WhileStatement = 'WhileStatement';
+export const YieldExpression = 'YieldExpression';


The only thing I do not like here is that there is no guarantee there is no typo between the types and the constants. Maybe each constant could also be explicitly given its type?

guybedford · 2018-05-03T22:34:29Z

@justinfagnani very good point - this support outputs a value that represents the URL of the output bundle in whatever environment it is run. In terms of asset loads / relocations I think perhaps using an asset API plugin is the better approach for that - import assetPath from './asset.ext'. Would be interested to hear your thoughts.

justinfagnani · 2018-05-03T23:19:30Z

@guybedford we have a transform that we run before files get to rollup that turns import.meta into:

{...import.meta, url: new URL(relativePathFromBundleToOriginal, import.meta.url).href}

Which preserves the original URL.

For much of our code at least, it's very important that import.meta give the same answer with and without bundling. Browsers don't support import assetPath from './asset.ext', so we can't do that.

guybedford · 2018-05-03T23:53:08Z

@justinfagnani interesting, yeah this also catches on some of the differences between workflows one might expect. Library authors may just want to output an import.meta.url statement, treating the build folder as relocatable, while application authors may want something closer to what you describe.

Perhaps there are some customization options that would work here. We could even open this up as a plugin hook for deeper flexibility like we do with dynamic import. I think we should definitely look into this for a future PR.

guybedford · 2018-05-03T23:56:33Z

Will put some further thought to this.

I think it's definitely worth noting though that use cases around import.meta.url are not currently fully fleshed out, and that we are still working on the approaches - it is under an experimental flag, but this makes me think perhaps we should give it its own experimental flag - experimentaImportMeta, so that we can stabilize it separately to the code splitting work.

justinfagnani · 2018-05-04T00:16:46Z

Library authors may just want to output an import.meta.url statement, treating the build folder as relocatable, while application authors may want something closer to what you describe.

I think library authors want the location preserving behavior. The use case is something like:

const css = await (await fetch(new URL('./my-component.css', import.meta.url).href)).text();

where you'll want the URL to point back to the original location so that ./my-component.css resolves correctly.

In Polymer we use this to fix up URLs in component templates for similar purposes.

guybedford · 2018-05-04T00:56:48Z

@justinfagnani I completely appreciate your use case.

Imagine too building a single-file library where you want that exact output, but your source file is in src/app.js being built into dist/build.js, where you know it will be fetching from dist/build.css.

It does seem like we need some options around the normalization behaviour to cater to different scenarios.

lukastaegert

From my side this looks good now! As for the comments by @justinfagnani:

Those are definitely valid use cases. I would still prefer the currently implemented approach as the default for two reasons:

The current approach will not transform import.meta.url for esm builds. For all other formats, it will be polyfilled in a way that aims to mimic the behaviour in the esm case.
In order to get information about the build before bundling there are different, though not necessarily elegant, ways of achieving this. Namely as all directory information is available before bundling, it would be possible to inject the meta information via a custom transformer plugin that replaces e.g. __dirname via the actual path or similar things. Information on the runtime environment, on the other hand, cannot be provided in such a way.

Still it might be interesting to see what other use-cases people have here and maybe provide a useful plugin hook to support those.

Jamesernator · 2018-07-05T11:37:05Z

Was some way added to allow hooking into the import.meta transform? As I'd like to use Rollup purely as an optimization that doesn't change any (major) semantics.

Basically I'd like to do pretty much the same thing as @justinfagnani suggested in his comments. That being having import.meta.url always be the same as where the file would've been if the module were loaded without bundling.

guybedford · 2018-07-16T15:31:34Z

@Jamesernator no this is still pending some work. Perhaps a importMetaUrl: 'relative' option could be implemented. PRs welcome.

justinfagnani · 2018-07-16T17:00:40Z

When would importMetaUrl: 'relative' ever not be the right option? We want module to work when they're not bundled, so import.meta.url has to point to where it would have before bundling, no?

What would other options even be?

guybedford · 2018-07-31T10:25:23Z

The other option is to wait until a clear solution presents itself, instead of rushing to create a feature that may incur technical debt in future :)

guybedford · 2018-07-31T10:28:15Z

How about a hook like the following:

resolveImportMetaUrl (id: string, outFile: string) {
  return resolved;
}

where if the return value is an absolute URL, it is used directly, and if it is a relative URL it is assumed relative to the outFile.

In this scenario, the following hook would effectively be the default as we have today:

resolveImportMetaUrl (id: string, outFile: string) {
  return './' + path.basename(outFile);
}

@justinfagnani @Jamesernator if that sounds like it might solve your use case, a PR along these lines is welcome, or I will see if I can get to this as well.

guybedford requested a review from lukastaegert April 27, 2018 19:19

guybedford force-pushed the import-meta-url branch 2 times, most recently from c049780 to 2a6b9e0 Compare April 30, 2018 20:57

guybedford mentioned this pull request May 2, 2018

[v8.x backport] url: expose the WHATWG URL API globally nodejs/node#20306

Closed

lukastaegert mentioned this pull request May 3, 2018

import.meta is a syntax error #2170

Closed

lukastaegert reviewed May 3, 2018

View reviewed changes

guybedford force-pushed the import-meta-url branch from 92fcdbe to 0457801 Compare May 3, 2018 23:49

lukastaegert approved these changes May 14, 2018

View reviewed changes

guybedford added 3 commits May 14, 2018 07:18

support import.meta.url output

74871c8

correct cjs fallback case

81e1177

initial pr feedback

78c6def

lukastaegert force-pushed the import-meta-url branch from 0457801 to 78c6def Compare May 14, 2018 05:22

lukastaegert added this to the 0.59.0 milestone May 14, 2018

lukastaegert added the fixed pending release label May 14, 2018

lukastaegert merged commit 78c6def into master May 14, 2018

lukastaegert deleted the import-meta-url branch May 14, 2018 05:26

lukastaegert removed the fixed pending release label May 15, 2018

LarsDenBakker mentioned this pull request Mar 10, 2019

Preserve import.meta.url from before bundling #2748

Closed

sapphi-red mentioned this pull request Jul 26, 2022

fix: avoid using import.meta.url for relative assets if output is not ESM (fixes #9297) vitejs/vite#9381

Merged

9 tasks

justinfagnani mentioned this pull request Jun 25, 2025

Logo not showing when bundled LeaVerou/bluesky-likes#19

Open

Uh oh!

Support import.meta.url #2164

Support import.meta.url #2164

Uh oh!

Conversation

guybedford commented Apr 27, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

justinfagnani commented May 3, 2018

Uh oh!

lukastaegert left a comment

Choose a reason for hiding this comment

Uh oh!

lukastaegert May 3, 2018

Choose a reason for hiding this comment

Uh oh!

guybedford May 3, 2018

Choose a reason for hiding this comment

Uh oh!

lukastaegert May 14, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lukastaegert May 3, 2018

Choose a reason for hiding this comment

Uh oh!

lukastaegert May 3, 2018

Choose a reason for hiding this comment

Uh oh!

lukastaegert May 3, 2018

Choose a reason for hiding this comment

Uh oh!

lukastaegert May 3, 2018

Choose a reason for hiding this comment

Uh oh!

lukastaegert May 3, 2018

Choose a reason for hiding this comment

Uh oh!

guybedford commented May 3, 2018

Uh oh!

justinfagnani commented May 3, 2018

Uh oh!

guybedford commented May 3, 2018

Uh oh!

guybedford commented May 3, 2018

Uh oh!

justinfagnani commented May 4, 2018

Uh oh!

guybedford commented May 4, 2018

Uh oh!

lukastaegert left a comment

Choose a reason for hiding this comment

Uh oh!

Jamesernator commented Jul 5, 2018

Uh oh!

guybedford commented Jul 16, 2018

Uh oh!

justinfagnani commented Jul 16, 2018

Uh oh!

guybedford commented Jul 31, 2018

Uh oh!

guybedford commented Jul 31, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

guybedford commented Apr 27, 2018 •

edited

Loading

lukastaegert May 14, 2018 •

edited

Loading

guybedford commented Jul 31, 2018 •

edited

Loading