Allow aliases to be resolved without an extra slash (#14370)

[Threebow]

Feature request

First off, thank you so much for all your amazing work on this project. I would like to propose the subject of a previously closed issue #14370, but this time as a feature request.

As described in #14370, TypeScript allows you to configure your project in a way that allows the following code:

import X from "@y"

This is accomplished using the following tsconfig.json options:

{
	"extends": "../../../tsconfig.base.json",
	"compilerOptions": {
		"outDir": "./dist",
		"rootDir": "./src",
		"paths": {
			"@": ["./src"],
			"@*": ["./src/*"]
		}
	}
}

Despite this, Webpack does not support a matching resolve.alias configuration option, and instead necessitates that you to fall back to the following unnecessarily extraneous and redundant style:

import X from "@/y"

When this was originally brought up in #14370, @alexander-akait mentioned that the reason why this doesn't work as you'd expect is because there may be naming conflicts between custom aliases and modules located in node_modules:

Because @utility is package name (yes, npm doesn't allow to use it, but it can be used potentially), you should use @/utility, it means resolve @ directory and looking for utility module

While I understand the implications of this, I feel quite strongly that if the user goes far enough to explicitly specify how they want a particular module identifier to be interpreted, (i.e. by explicitly mapping ~alias or @utility in TypeScript's compilerOptions.paths or Webpack's resolve.alias), that Webpack should respect that. TypeScript allows the exact same.

What is the expected behavior?

I believe that Webpack should allow you to write the first (and objectively more logical) import style, as such:

import X from "@y"

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

As mentioned above:

I feel quite strongly that if the user goes far enough to explicitly specify how they want a particular module identifier to be interpreted, (i.e. by explicitly mapping ~alias or @utility in TypeScript's compilerOptions.paths or Webpack's resolve.alias), that Webpack should respect that. TypeScript allows the exact same.

Additionally, the combo of Webpack + TS already gives us great freedom to augment our application development with QOL improvements, and this feels like a natural step in that direction. I can't imagine anybody that wouldn't benefit from this feature being added.

How should this be implemented in your opinion?

As mentioned earlier, I understand and recognize the issue of conflicting package names. To remedy this, this feature could be disabled by default, and made accessible only by enabling a specific webpack configuration option. As for the internal implementation details, I am not so sure, but I would be happy to look if you are open to accepting a pull request for this.

Are you willing to work on this yourself?

I will happily work towards submitting a pull request for this, if this is something that you would be interested in merging. Let me know.

Footnotes

Thank you for reading my issue and again thank you for all your work on this tool. It is much appreciated.

P.S. If anyone knows of a loader or plugin that implements this already, please let me know, as I couldn't find one 😃

[tehreet]

This is one of the best issues I've seen in a long time, really well written.

[alexander-akait]

PR welcome

[log101]

@Threebow TsconfigPathsPlugin does exactly what you're trying to do, you can check it out.