#163967 css aliases

[SStranks]

Issue #163967: [css] Custom aliases in CSS file resolution
In conjunction with Pull Request #368

Functionality

Main functionality is in the aforementioned pull request. The changes in this pull request allow the user to specify the alias settings that are to be consumed by the css-language-service to allow for ctrl-click file link navigation for aliased imports within CSS and SCSS files.

Changes

Package.json:
Added an 'alias.path' object, for both css and scss, that allows a user to specify an alias and an associated path. Object has pattern constraints to ensure correct syntax and mirroring the behaviour of alias settings in a tsconfig.json file (under 'compiler.paths').

Package.nls.json:
Added the associated tool tip descriptions to guide the user on using the settings.

[SStranks]

@microsoft-github-policy-service agree

[niksy]

Since microsoft/vscode-css-languageservice#368 is merged, are there any blockers for merging this?

[aeschli]

What are valid paths? Relative, absolute? Resolved against what?

[miss-programgamer]

Any updates on this? I don't see a reason why this stayed in limbo for more than a year.

[aeschli]

See my question on #197033 (comment)

[miss-programgamer]

I did see your question, it makes you look completely clueless. If I must explain though, the point of this pr is to allow users to configure intellisense so that it's aware of any CSS/SCSS import aliases they may have configured in their bundling tools (webpack, vite, etc.). It's roughly the same as the compilerOptions.paths property in tsconfig.json files.

Seriously, just read the text of this very pr and you'll get the answers to your questions. It's explained in words I would struggle to put any simpler, how did you not understand? "What are valid paths?" what the user decides, what the hell kind of question is that? Get someone else to take this task over if you hold so much disdain for it.

[aeschli]

Paths in tsconfig are relative to the location of the tsconfig file. The TypeScript spec describes that.
The spec for this setting needs to describe the same. Right now it says 'relative to the current project root folder.'.

• that's not what the implementation does
• VS Code doesn't have a 'project root folder'. We have either no, one or multiple workspace folders. What happens if there's no folder?

[miss-programgamer]

The project root in this case would be wherever the package.json file is, which is also where the setting is stored in the first place, which again, you could have deduced by reading the text of the pull request.

Edit: took a closer look, realized there's also a setting for .vscode/settings.json, and thought about it more. In what world is there any ambiguity in where the root of a project is? If no folder is open, there can't possible be a root, so just don't resolve aliases. If there's a folder open, then the root is the root of that folder. If it's a multi-workspace folder, then resolve aliases for files depending on which workspace they're contained in. And if a file from outside any folder is opened, do the same as when no folder is open, just do nothing. Also whatever's in the package.json file should override vscode's settings in case of conflicts.

All the possible cases have exactly one obvious resolution to them, so I ask again: what exactly is ambiguous about literally any of this?

[aeschli]

Thanks for the explanation.
So lets make sure that also users of the new alias setting understand this, without them having to look at the implementation
Also fix the implementation so it does what you describe. Also I would have expected some code that validates any of these path before giving them to the server
This is what I understand from the implementation

• if the path is relative (starts with a dot) the alias is resolved against the document location
• if the path is absolute, it is resolved against the documents workspace folder.
• if there's no root folder, the path is resolved against the filesystem root (likely a bug)
• I don't see any handling of package.json.

So, next steps, please clarify the user setting and fix the implementation.

[miss-programgamer]

See, that's far more actionable than your "huh? wuh???" response from a year ago.

Frustrations aside, is the author of this pr even listening? He hasn't piped up during this entire interaction. Maybe someone else should take this over huh.

[SStranks]

Frustrations aside, is the author of this pr even listening? He hasn't piped up during this entire interaction. Maybe someone else should take this over huh.

Hi 👋 The associated PR request #368 was actually merged already - it's been such a long time, but pretty sure it was working when I was developing it locally.

I'll set it up again and test it out.

EDIT:
Debugging: It does actually work but only for single-root workspaces, making use of a .vscode/settings.json file at the root of that workspace.

It breaks for multi-folder workspaces - the issue now has to do with how 'settings' are passed down; the actual file resolution using documentContext in documentContext.ts returns the correct root folder in a multi-folder workspace, but 'settings' become null. I think I can see what to amend in order to make it multi-folder supported.

I will make a new PR to update the code, then update the package.json/package.nls.json to satisfy @aeschli questions/observations.

[SStranks]

@aeschli

Taking everything so far into account, I amended the descriptions in package.nls.json to better describe the functionality; I have updated the functionality in a parallel PR request on the css-languageserver repo: #460

The feature now supports single-root, multi-root, and mono-repo style setups.