Relative `alias` resolution for monorepos

Feature request

In monorepos, use of “common packages” is widespread. Files of these common packages can be referenced directly from other packages, and be put together into one webpack.config.js, with a single output.

However, different packages might have common aliases, which should resolve differently per package. Example: the src alias should point to the package’s src folder.

What is motivation or use case for adding/changing the behavior?

Example:

• 2 packages: App and common-lib.
• There is only one webpack.config.js in the project. It is to build App.
  • common-lib does not need to be built independently. It is only to be used in conjunction with other modules.
• Files in App can directly import files from common-lib (usually by configuring resolve.modules and resolve.alias).

Problem: some aliases are package-relative. Most commonly: the src alias. (It is so common in fact, that VSCode automatically resolves to src, if it is shorter than a relative import, even though, if baseUrl is configured, and src is in baseUrl.)

How should this be implemented in your opinion?

The alias configuration option can take a function which (or provide some other way where it) resolves the same alias differently, depending on where it is used.

This enables the following scenario:

• import from 'src/X';
  • should resolve to App/src/X, if used in App
  • should resolve to common-lib/src/X, if used in common-lib

Are you willing to work on this yourself?

Maybe, depends on feedback.

[alexander-akait]

You can achieve this using:

• different alias for import from 'src/X';, i.e. in app using import something from 'app/src/x', in common using import something from 'common/src/x' and write for them aliases
• using imports https://nodejs.org/api/packages.html#packages_imports (preferable due it will work without webpack too)
• implement a plugin https://github.com/webpack/enhanced-resolve
• write a loader and rewrite import on necessary file
• refactor code and using different imports modules

Also it is not good for ESM, because in real world the same URL in import should resolve the same file (don’t forget import is cached), so because it is non standard, please use any custom solution from above, thanks

[alexander-akait]

When you bundle multiple multiple version of package, each modules have identifier (it is path to module i.e. for example if you have require("package") and some package also have require("package") you will have node_modules/package/index.js and node_modules/another-package/node_modules/package/index.js), so you will have two versions of packages.

As I written above you can create a custom plugin for resolver and implement any logic. module federation is some other technology, it allow to share modules in runtime and reuse them, so you can create micro architecture.