✅ Deploy Preview for rspack canceled.

Built without sensitive environment variables

CodSpeed Performance Report

Merging #10573 will not alter performance

_{Comparing magic-akari:fix/issue-8008 (b6acc0a) with chore/add-import-meta-desctructuring-hook (127450f)}

Summary

✅ 17 untouched

I haven't yet implemented import.meta.resolve, which provides functionality similar to require.resolve but follows ESM resolution rules.
Since we're currently unsure about the best approach to implement this (and would welcome insights if you have them), I've decided to hold off on implementation for now.

done.

On Windows CI, import.meta.url handles file paths differently (using three slashes versus two). Since this PR doesn't address that specific behavior, we'll defer fixing it for now.

- 	expect('file://<TEST_TOOLS_ROOT>/tests/builtinCases/plugin-javascript/import-meta/index.js').toBe(url);
- 	expect('file://<TEST_TOOLS_ROOT>/tests/builtinCases/plugin-javascript/import-meta/index.js').toBe(url);
- 	expect("my" + 'file://<TEST_TOOLS_ROOT>/tests/builtinCases/plugin-javascript/import-meta/index.js').toBe("my" + url);
+ 	expect('file:///<TEST_TOOLS_ROOT>/tests/builtinCases/plugin-javascript/import-meta/index.js').toBe(url);
+ 	expect('file:///<TEST_TOOLS_ROOT>/tests/builtinCases/plugin-javascript/import-meta/index.js').toBe(url);
+ 	expect("my" + 'file:///<TEST_TOOLS_ROOT>/tests/builtinCases/plugin-javascript/import-meta/index.js').toBe("my" + url);

@LingyuCoder @h-a-n-a cc~

@LingyuCoder can you help to review this PR?

@LingyuCoder 😅

LGTM, im not sure if a new experiment option should be added @chenjiahan

@LingyuCoder Can you help to check this issue (webpack/webpack#18320) and provide some advice?

@LingyuCoder Can you help to check this issue (webpack/webpack#18320) and provide some advice?

I just think it should align with the behavior of Node.js and adding an new experiment option to facilitate modifications in case of inconsistent behaviors after the implementation of webpack in the future.

Since this is not a very stable specification, it's uncertain whether it is consistent across bundlers and Node.js. Considering that rspack should currently align with webpack in this behavior, you might consider submitting a PR to webpack and getting their advice too 😊

A PR has now been merged in webpack:

• feat: added support for import.meta.dirname and import.meta.filename webpack/webpack#20050

Hi team! 👋

I noticed that webpack's implementation for import.meta.dirname and import.meta.filename is in NodeStuffPlugin (from webpack PR #20050), so I attempted to migrate our implementation to follow the same architecture.

✅ What's Working

I've successfully migrated the member access handling to NodeStuffPlugin:

// Now in NodeStuffPlugin
import.meta.dirname  // ✅ Respects node.dirname config
import.meta.filename // ✅ Respects node.filename config

This works well and follows webpack's pattern using the unified handle_dirname_or_filename method, matching webpack's dirnameAndFilenameHandler approach.

Supported Node Options

The implementation reuses the existing NodeStuffPlugin logic for CommonJS __dirname/__filename, which already handles various node configuration options:

• false
• mock
• warn-mock
• node-module
• eval-only
• true

⚠️ Challenge: Destructuring Support

However, I encountered an architectural limitation with destructuring assignment:

const { dirname, filename } = import.meta

How webpack handles this

In webpack, destructuring is handled through a hook mechanism:

1. ImportMetaPlugin processes destructuring and calls hooks.propertyInDestructuring for each property:

   for (const prop of referencedPropertiesInDestructuring) {
       const value = hooks.propertyInDestructuring.call(prop);
       if (value) {
           str += value;  // Use value from hook
           continue;
       }
       // Otherwise handle in ImportMetaPlugin
   }

2. NodeStuffPlugin registers handlers on this hook to provide values based on node.dirname/node.filename config:

   hooks.propertyInDestructuring.tap(PLUGIN_NAME, (usingProperty) => {
       if (usingProperty.id === property) {
           return `${property}: ${fn(parser.state.module)},`;
       }
   });

3. This allows NodeStuffPlugin to inject the correct values during destructuring

The rspack limitation

In rspack, we don't have a propertyInDestructuring hook:

• ImportMetaPlugin directly handles all destructured properties in the meta_property method
• There's no mechanism for NodeStuffPlugin to intercept and provide node-config-aware values
• This means destructuring currently returns simple file paths, ignoring node config

// Current rspack implementation in ImportMetaPlugin
match prop.id.as_str() {
    "url" => { /* ... */ }
    "filename" => {
        // NodeStuffPlugin cannot intercept this!
        content.push(format!(r#"filename: "{}""#, self.import_meta_filename(parser)));
    }
    "dirname" => {
        // NodeStuffPlugin cannot intercept this!
        content.push(format!(r#"dirname: "{}""#, self.import_meta_dirname(parser)));
    }
    // ...
}

🤔 Question for the Team

I'd appreciate your guidance on which approach to take. Here are the three options I see:

Option 1: Don't migrate to NodeStuffPlugin - Keep implementation in ImportMetaPlugin, ignoring node options

• ❌ Creates architectural inconsistency with webpack

Option 2: Migrate to NodeStuffPlugin - Member access respects node options, but destructuring doesn't

• ✅ Member access behavior aligns with webpack
• ❌ Introduces internal inconsistency in rspack (member access and destructuring behave differently)

Option 3: Wait for hook mechanism - Implement propertyInDestructuring hook first, then complete the migration

• ✅ Full webpack parity
• ⚠️ Requires Rspack team investment to implement the hook mechanism

I'm happy to proceed with any of these approaches based on your preference. Thank you for your guidance!

📚 References

• Webpack PR: feat: added support for import.meta.dirname and import.meta.filename webpack/webpack#20050
• Webpack NodeStuffPlugin: https://github.com/webpack/webpack/blob/main/lib/NodeStuffPlugin.js
• Webpack ImportMetaPlugin: https://github.com/webpack/webpack/blob/main/lib/dependencies/ImportMetaPlugin.js

Option 3: Wait for hook mechanism - Implement propertyInDestructuring hook first, then complete the migration

• ✅ Full webpack parity
• ⚠️ Requires Rspack team investment to implement the hook mechanism

Since the propertyInDestructuring is a plugin private hook of ImportMetaPlugin rather than a parser hook, and it should not affect the parser. So I think we can follow webpack's design and add this hook to ImportMetaPlugin to support the behavior of the NodeStuffPlugin. What is your opinion? @ahabhgk

I'm ok with the current implementation, only thing need to change is ImportMetaPlugin need to read the config from parser.compiler_options.node. IMO the propertyInDestructuring is a bit make code complex

Just to follow up, is the configCases/module-variables test case deprecated? I still can't seem to find the corresponding files in webpack repo.

Just to follow up, is the configCases/module-variables test case deprecated? I still can't seem to find the corresponding files in webpack repo.

This case is still in use and it should be a test case specific to rspack.

Webpack import.meta.dirname/filename Feature History

This document was generated by AI to summarize the webpack commits that implemented support for import.meta.dirname and import.meta.filename.

Commit Timeline

1. a576d0f31 - 2025-10-28

feat: added support for import.meta.dirname and import.meta.filename

Files Modified:

• lib/NodeStuffPlugin.js - Core implementation
• lib/config/defaults.js
• lib/dependencies/CommonJsPlugin.js
• lib/dependencies/ExternalModuleInitFragment.js
• Added test cases in test/configCases/node/filename-and-dirname/

Features:

• Initial implementation of import.meta.dirname and import.meta.filename support
• Extended NodeStuffPlugin to handle ESM modules by registering handlers for import.meta.dirname and import.meta.filename
• Support for various node.__filename and node.__dirname configuration values:
  • true - Replace with relative path from context
  • false - Keep import.meta.filename/dirname as-is (for Node.js runtime)
  • "mock" - Replace with /index.js or /
  • "warn-mock" - Same as mock but with warning
  • "node-module" - Use fileURLToPath(import.meta.url) polyfill
  • "eval-only" - Keep as import.meta.filename/dirname for ESM output

Key Implementation:

// Keep `import.meta.filename` in code when node.__filename is false
if (
    localOptions.__filename === false &&
    filename === "import.meta.filename"
) {
    parser.hooks.expression
        .for(filename)
        .tap(PLUGIN_NAME, toConstantDependency(parser, filename));
}

2. 78ddad1ba - 2025-10-31

feat: support destructuring for import.meta.filename and import.meta.dirname

Files Modified:

• lib/NodeStuffPlugin.js - Major refactoring
• lib/WebpackOptionsApply.js
• lib/dependencies/ExternalModuleInitFragmentDependency.js (new file)
• lib/dependencies/ImportMetaPlugin.js - Added hook system
• lib/javascript/JavascriptParser.js

Features:

• Support for destructuring syntax: const { dirname, filename } = import.meta;
• Added ImportMetaPlugin.getCompilationHooks(compilation).propertyInDestructuring hook
• Modified ImportMetaPlugin.unhandledExpressionMemberChain to skip dirname and filename
• When parserOptions.node === false, still register handlers to preserve import.meta.dirname/filename as-is

Key Implementation:

// In ImportMetaPlugin - skip dirname/filename in unhandledExpressionMemberChain
if (
    members[0] === "env" ||
    members[0] === "dirname" ||
    members[0] === "filename"
) {
    return true;
}

// In NodeStuffPlugin - handle parserOptions.node === false
if (b && parserOptions.node === false) {
    // Keep `import.meta.dirname` and `import.meta.filename` in code
    setModuleConstant(parser, "import.meta.dirname", () => "import.meta.dirname", "dirname");
    setModuleConstant(parser, "import.meta.filename", () => "import.meta.filename", "filename");
    return;
}

3. 8651ffc23 - 2025-10-31

feat: handle import.meta.main

Files Modified:

• lib/dependencies/ImportMetaPlugin.js

Features:

• Added support for import.meta.main property
• Not directly related to dirname/filename but part of the import.meta enhancement series

4. a2938e240 - 2025-11-07

feat: support __dirname/__filename/import.meta.dirname/import.meta.filename for universal target

Files Modified:

• lib/NodeStuffPlugin.js
• Added test cases for universal target

Features:

• Extended support to work with target: "universal"
• Ensures consistent behavior across different target configurations

5. 2259e2cc9 - 2025-11-19

fix: compatibility import.meta.filename and import.meta.dirname with eval devtools

Files Modified:

• lib/NodeStuffPlugin.js
• lib/dependencies/CachedConstDependency.js
• lib/dependencies/ExternalModuleDependency.js
• lib/dependencies/ExternalModuleInitFragment.js
• lib/dependencies/ExternalModuleInitFragmentDependency.js

Features:

• Fixed compatibility issues when using devtool: "eval"
• Ensured proper handling of external module dependencies in eval context
• Added more test configurations for eval devtool scenarios

6. 05cac61aa - 2025-11-25

feat: enhance import.meta.env to support object access

Files Modified:

• lib/dependencies/ImportMetaPlugin.js

Features:

• Enhanced import.meta.env support
• Not directly related to dirname/filename but shares similar patterns in ImportMetaPlugin

Summary of Key Behaviors

Hi @LingyuCoder, I expected this PR would automatically rebase onto main after chore/add-import-meta-desctructuring-hook was merged, but it seems to have been closed unexpectedly instead.
Would you mind helping to reopen this PR? Thanks!

Never mind! I've already opened a new PR(#12317) instead. Thanks anyway!