[Bug]: import var names are derived from redirected request rather than the original import string

[dinofx]

System Info

macOS
rspack version 1.3.8

Details

Summary

We are seeing really long import var names in our generated code compared to what webpack would produce. This impacts dev mode, where the variable names used are no longer easily readable. It also affects our ability to write reliable test fixtures because the generated output is different for each developer.

Background

Our build system does not use standard node module resolution. When we build a package, its package dependencies come from a directory outside the current build's context. With webpack, we used various NMF hooks to alter how modules were resolved and created. In Rspack, we use the replacement described here, so we have code like that example:

compiler.hooks.normalModuleFactory.tap('PLUGIN', normalModuleFactory => {
  normalModuleFactory.hooks.resolve.tap('PLUGIN', data => {
    // Redirect the module
    if (data.request === './foo') {
      data.request = './bar';
    }
  });
});

So we might have a request to another package like 'react' or our 'I18n' package, and it gets redirected to some absolute path like '/Users/rhudson/.hubspot/static-archive/I18n/v7.1234/js/index.js'. This lets our custom resolution work, but we end up with undesirable var names like:

/* ESM import */var _Users_rhudson_hubspot_static_archive_I18n_v7_1234_js_index_js__WEBPACK_IMPORTED_MODULE_3__ = __webpack_require__(/*! ../../../../.hubspot/static-archive/I18n/v7.1234/js/index.js */ 361);

compared to the same import var produced by webpack:

/* harmony import */ var I18n__WEBPACK_IMPORTED_MODULE_3__ = __webpack_require__(/*! I18n */ 358);

Note the inline comment is also more verbose, but I think that could be turned off.

I think these var names are coming from this code:

rspack/crates/rspack_core/src/compiler/compilation.rs

Line 586 in 20dce0d

let user_request = to_identifier(module_dep.user_request());

I suspect that the user_request at this point is no longer the original imported string, but is actually the final request after any NMF hooks have redirected the request elsewhere.

Proposal

Would it make more sense for these var names to reflect the original import/dependency in the source code, before hooks have altered it? We have additional hooks that insert inline loaders, etc., so the naming can get even worse than the example above. It seems like this would more closely match webpack's behavior, where I'm guessing the intent is for these vars to be human readable. If so, it would be great if the inline comment were the same.

Reproduce link

No response

Reproduce Steps

I suspect the example I linked to from the docs is affected to a lesser degree. Where the code originally imported "foo", the generated code probably ends up with a var name containing "bar"

[dinofx]

It looks like the issue is user_request isn't really represented, right? I found this code:

rspack/crates/rspack_core/src/dependency/module_dependency.rs

Lines 11 to 13 in bdfde82

	fn user_request(&self) -> &str {
	self.request()
	}

Which suggests the original user request isn't being stored, right? Could an optional user_request field be added and, if some hook redirects the request, the user_request would become populated with the original value? If the request is never altered, it could fall back to returning the request.

[Austaras]

Already fixed by #10999