The @/ alias lives in three configs, and all three are required

Banning ../../.. is easy to say and hard to make true across three toolchains. This site points @/ at src, configured in three places, each owning one pipeline.

What each place owns

• vite.resolve.alias in astro.config.mjs: module resolution for bundling and dev.
• paths in tsconfig.json: editor completion and type resolution for astro check.
• loadPaths for SCSS: path resolution inside @use.

These are three independent resolution chains. None of them reads the others.

Symptoms of missing one

Vite only: @/components/X.astro is red in the editor but the build passes. tsconfig only: the editor is happy and the build cannot find the module. No loadPaths: @use of a root-relative style path fails with File not found.

None of those three symptoms suggests the same cause, which is why a table beats memory here.

Why styles do not use @/

SCSS @use does not go through the Vite alias; it only honours loadPaths. So styles are written as root-relative paths:

@use 'styles/settings/tokens';

That is the same destination as @/, expressed for a different toolchain. Neither can replace the other.

The two exceptions that must stay relative

import.meta.glob is statically analysed at build time: Vite requires literal paths, aliases do not apply, and the pattern cannot live in a variable. So the app registries in lib/registry.ts and lib/mount.ts are the only relative paths left. That is a framework limit, not an oversight.

What it buys

Moving a file no longer touches import statements, @/ is instantly distinguishable from a package import, and directory depth stops affecting readability. The price is that these three configs must change together, which is easy to forget during a reorganisation.