📎 Support for path aliases

[ematipico]

There have been some discussions already in some other issue.

Some code bases take advantage of path aliases to handle how they import their modules.

import Sidebar from "@components/sidebar";

TypeScript supports them but it doesn't transform them. I think Rome should support them too - and ultimately transform/explode them during the bundling. Path aliases will be beneficial for the linter and the bundler (and testing as direct consequence).

We could use the command rome auto-config to "import" the aliases defined inside a tsconfig.json file. We could add a new configuration called aliases and have a structure like:

"aliases": {
    "@components": "src/components",
    "~layouts": "src/pages/layouts"
}

The name aliases is purely conventional and we can change it. If you have a better suggestion please leave a comment.

The paths defined on the right-side (e.g. "src/components") would start from the "root" of the project, where the configuration file is defined.

Is there anything that I missed?

[JustBeYou]

tsconfig.json supports multiple locations for the same alias:

"paths": {
     "@components": ["./components", ... other paths ...]
}

I think we should support the same syntax if we want it to be fully compatible.

[ematipico]

@JustBeYou as you expressed your interest working on this, please consider also this comment.

The support should be explicit and Rome should not rely on third party API/libs for features. This means that even though a project has path aliases already set already in the tsconfig.json, the configuration should be explicit via rome auto-config or manually set.

[JustBeYou]

Sure, I know that the philosophy here is zero dependencies. I think the fix would go somewhere in the resolver, probably somewhere around resolveLocal.

[jamiebuilds]

One question we should answer is if tsconfig.json paths should apply to more than just JavaScript/TypeScript.

{ "paths": { "@components/*": ["./src/components/*"] } }

@import "@components/button/styles.css"

etc

That might make sense at first, but consider the use case of Rome where someone isn't using TypeScript or even JavaScript.

[jamiebuilds]

An alternative is to make the paths in tsconfig.json "managed" by Rome, as in automatically keep it in sync or yell if they disagree. There's already a number of ways I'd like to see tsconfigs managed by Rome anyways

I like how TypeScript uses a glob-like matching system over the regex stuff webpack does. But we also may be able to do a better job.

[robpalme]

FYI this feature may overlap with Node's package imports which provides a more constrained form of remapping module specifiers with a package.

https://nodejs.org/api/packages.html#packages_subpath_imports

[JustBeYou]

@ematipico do you know if this node feature is already supported by rome? If not, I think we need to decide if we should manage it like for tsconfig or not. Or maybe we shouldn't allow using both features?

[ematipico]

@ematipico do you know if this node feature is already supported by rome? If not, I think we need to decide if we should manage it like for tsconfig or not. Or maybe we shouldn't allow using both features?

Nope, at the moment the resolution of exports field inside a package.json is turned of on purpose, which means that at the moment we don't support sub paths and conditional exports.

Resolution on imports are not existent at the moment, I think.

We'll need to support sub paths, for sure. Although with Rome we can even go further and extend the feature to CSS files and HTML files.

We can support both. Subpaths work on dependencies, aliases work on the internal code base. If there's a clash Rome can:

• resolve node first, codebase second
• throw a diagnostic saying that #components subpath clashes with aliases, and suggest to the user a different symbol, e.g. @components, $components, etc.

The choice is ours. I think a diagnostic is actually better. Less magic, more control.

[rdsedmundo]

@ematipico I see you closed this as completed, but I couldn't find the solution on Rome docs for that. I'd like something highly configurable like it's possible to do with webpack, TypeScript and Jest, where besides aliases you can just pass an arbitrary module as well that exports a known interface and implement a complete custom module resolution.

[ematipico]

@rdsedmundo this is an old issue, before the Rust rewrite. Since then we rewrote the tool in Rust and dropped features that will be implemented in the future

[rdsedmundo]

@ematipico I understand. Would it make sense to re-open this issue then? Or should I create a new one?

[ematipico]

It would make more sense to open a new discussion. And when we're are ready to work on this feature, we can open a new issue