generated tsconfig.json

[Rich-Harris]

Groundwork for #647. This adds a generated .svelte-kit/tsconfig.json and checks that the user's config (if such exists) extends it.

This allows us to make changes like #3064 that existing apps can take advantage of (rather than only newly created apps), including the change I have planned that will address #647.

It also allows us to base certain values on the user's configuration. For example, if someone were to specify a different lib folder...

// svelte.config.js
export default {
  kit: {
    files: {
      lib: 'src/my-stuff'
    }
  }
};

...then we can automatically generate the correct alias:

{
  "paths": {
    "$lib": ["../src/my-stuff"],
    "$lib/*": ["../src/my-stuff/*"]
  }
}

I'm not sure how much of the existing compilerOptions is necessary, but I figured I'd keep it there for now unless people have thoughts.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: dd83df1

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
create-svelte	Patch
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Conduitry]

Are we worried about losing these comments in the generated tsconfig file that gets included? Does tooling generally provide a way to look at the file being extended, and do we care if that becomes less readable.

Or, another way of asking it: was the only reason for the user-visible comments so that people could know which config options not to mess with?

Also sort of relatedly: Do you foresee us potentially wanting to warn or error out if the user config does override certain essential values from the generated config?

[Rich-Harris]

I'm not particularly worried about the comments. Though I do think it's probably a good idea to warn if the user specifies incompatible values (as already happens with compilerOptions.paths)

[Conduitry]

Is there anything similar we'd want to do with jsconfig.json? Does that support extends in the same way?

[Rich-Harris]

jsconfig.json works exactly the same way, yeah (in fact i've been testing all this with a jsconfig)

[Conduitry]

Oh whoops, I missed in the diff that you'd updated the jsconfig in the starter templates as well to extend the same file. Never mind, nice!

[benmccann]

I left a few stylistic comments, but LGTM

[janosh]

I'm getting warnings in lots of projects following this PR.

Your tsconfig.json should extend the configuration generated by SvelteKit:
{
  "extends": "./.svelte-kit/tsconfig.json"
}

Just adding the above lines to tsconfig.json doesn't seem like a good solution as it would break all CI scripts that run tests without calling svelte-kit dev/build first:

Error: failed to resolve "extends":"./.svelte-kit/tsconfig.json"

What's the recommended setup now?

[Conduitry]

I'd say the recommendation is to wait for #4182 to be released.

[ghost]

After this PR, I am now unable to resolve imports to asset files. It seems that the generated tsconfig defaults to only including *.js, *.ts, and *.svelte files. Unfortunately this also means that importing such files as assets/styles.css result in a vite error when building the project.

I have resolved this issue by adding the following to my tsconfig:

{
    "extends": "./.svelte-kit/tsconfig.json",
    "include": ["src/**/*"],
    "exclude": [],
}

I do think that this makes more sense than only allowing .js, .ts, and .svelte files, because many users are going to want to make use of vite's asset handling features.

I think it would be beneficial and avoid some confusion to implement the following behaviour as default:

• include all files inside the directory specified in config.kit.files.assets
• include all .js, .ts, and .svelte files inside src/ (existing behaviour) and inside the hooks, lib, and routes folders specified in config.kit.files (in case the user specifies custom locations for these folders)

---

Edit

It seems this error occurs specifically when using baseUrl setting in tsconfig.json (where the vite-tsconfig-paths package is required to resolve baseurl imports).

However, the existing behaviour of the tsconfig generation still does not solve the problem of custom paths as specified inside config.kit.files. For example, if I set routes to be a folder routes/ in the root directory of my project, this directory is not included inside the tsconfig project.

[benmccann]

@applemonkey496 could you file a new issue about this so that we can track it? It will get lost as a comment on a closed PR