About Boundaries for Transpiling import.meta

[magic-akari]

In SWC's current implementation, we transpile certain import.meta syntax like import.meta.url, including similar forms such as import.meta.dirname and import.meta.resolve.

However, this doesn't cover all cases. Consider import.meta?.url:

• Naively transpiling this to { url: some_expr }?.url would be redundant—it always simplifies to some_expr.
• As per the ECMAScript specification, import.meta?.url is indeed always equivalent to import.meta.url. This is because import.meta is guaranteed to be a non-null Object

Note

"Object" in the ECMAScript spec excludes null; reference:

• https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-meta-properties
• https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-object-type
• https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-ecmascript-language-types-null-type

Related issues:

• es/transpiler: optional chain on import.meta results in import.meta not getting transformed despite preserveImportMeta: false #10988
• fix(es/module): Support optional chaining in import.meta #10985

Rollup's playground appears to handle both identically—as if import.meta?.url gets evaluated to import.meta.url during transpilation. Should we adopt similar simplification?

The boundary cases extend further:

1. Destructuring:

   const { url, dirname } = import.meta;

   Could this be transpiled to:

   const { url, dirname } = { url: expr_1, dirname: expr_2 };

   Should we support this?

2. Destructuring in For-Loop:

   for (const { url, dirname } of [import.meta]) {
       console.log(url, dirname);
   }

   Transpilation becomes increasingly challenging here.

3. Reference Passing & Runtime Checks:
   Cases where correctness is unattainable:

   let x = import.meta;
   foo(x); // or foo(import.meta);
   
   function bar(x) {
       return [x === import.meta, Object.getPrototypeOf(x) === null]; // Runtime identity/prototype checks
   }

   For this direct references to import.meta itself (rather than its properties), I recommend leaving the syntax untranspiled (as-is) for the runtime to handle. Rollup's transpilation of similar cases has proven error-prone.

Core Question: Where should we draw the line for import.meta transpilation?

[kdy1]

I think we should not support destructuring now. It may be worth supporting if we have a general way to transform everything with a single code, but we don't have a such way at the moment

[magic-akari]

What about import.meta?.url?

[kdy1]

I don't have a strong opinion about it. What's your opinion?

I think import.meta can be too complex for some edge cases like foo(import.meta) though.

[PeterCardenas]

i wonder if we should explicitly error out in these cases? or is that not the attitude we want to have