`config.kit.alias`

[Rich-Harris]

Describe the problem

Could have sworn we already had an issue for this. Anyway. Custom aliases are a tiny bit confusing at the moment, because you have to declare them in both the Vite config and the TypeScript config, using very different approaches:

const config = {
  kit: {
    vite: {
      resolve: {
        alias: {
          $utils: path.resolve('src/utils')
        }
      }
    }
  }
};

{
  "compilerOptions": {
    "paths": {
      "$utils": ["src/utils"],
      "$utils/*": ["src/utils/*"]
    }
  }
}

And because of the tsconfig merging logic, as soon as you declare custom aliases you have to take care to also declare the $lib alias...

{
  "compilerOptions": {
    "paths": {
+      "$lib": ["src/lib"],
+      "$lib/*": ["src/lib/*"],
      "$utils": ["src/utils"],
      "$utils/*": ["src/utils/*"]
    }
  }
}

...even if you're not using it, which annoys some people.

Describe the proposed solution

const config = {
  kit: {
    alias: {
      $utils: 'src/utils'
    }
  }
};

For Vite, we add [key]: path.resolve(project_root, value).

For TypeScript, we add [key]: value, [key + '/*']: value + '/*'.

People still have the ability to use the more complex options if they so choose, but this takes care of common cases.

Alternatives considered

Not doing this, on the grounds that overusing aliases is problematic.

Importance

nice to have

Additional Information

No response

[furudean]

Any thoughts about introducing $: path.resolve("./src") as a default over forcing $lib as a de-facto standard? Gives you $/lib/whatever.js and $/anything/you/want.js with zero config. Seems more flexible than providing an alias to just $lib.

[Mlocik97]

I would definitelly not like to write $src/lib/file instead $lib/file.... and you would still need this "alias" feature, as if you change structure of project, or have multiple nested folders, you would like to configure it anyway.

[Rich-Harris]

@furudean We don't want to encourage people to import things like $src/hooks.js or $src/routes/__layout.svelte — that would lead to people putting things in the wrong places just because they can. If something is used in multiple parts of the app, src/lib is where it goes.

It's also what defines your package, if you're using svelte-kit package.

---

Another reason we might want to implement this is that people might use custom aliases in src/lib, and at the moment only $lib is resolved. We could resolve other aliases based on config.kit.vite.resolve.alias or the tsconfig, but both of those have drawbacks, so having a single source of truth could be easier.

Then again, I stand by "overusing aliases is problematic", and it's probably good to nudge people towards just using lib everywhere.

[Mlocik97]

I use $lib everywhere, and actually I find it the best approach... it was enough for me in nearly every case, and I think it's enough for a lot of people in most cases. So I agree with Rich.

[Azarattum]

@Rich-Harris I just raised an issue on the same subject (#4774) as this has been an annoyance to several of my projects... There I proposed to use the existing vite aliases, since they are already there, so should be easier to implement. But I think config.kit.alias would be a nicer solution. And also without all that resolve nonsense.

[Mlocik97]

I wouldn't delete "resolve()" thing, because in case of monorepo, if you want to point to another repo (with some library for example) then without path.resolve() it would be problem...

[bluwy]

I'm a bit concern of duplicating places to define aliases, either in config.kit.alias and config.kit.vite.resolve.alias. Would it be possible for the auto tsconfig generation to resolve the Vite config, retrieve the Vite aliases, and generate the tsconfig from there?