Add paraglide lib stuff to eslint and prettier ignore files

[jackvanderbilt-visma]

Describe the problem

When I setup a new project I have to manually add src/lib/paraglide to the eslintignore and prettierignore configs.

When making github CI/CD workflows, its annoying to have to do myself, when the CLI could've done this for me.

Describe the proposed solution

Please add them for me automatically.

Importance

nice to have

[benmccann]

I feel like the better solution would be to change outdir: './src/lib/paraglide' to something in .svelte-kit. I'm not that familiar with paraglide or what it's outputting there, but src/lib is meant for source code and not generated output

[manuel3108]

I feel like the better solution would be to change outdir: './src/lib/paraglide' to something in .svelte-kit. I'm not that familiar with paraglide or what it's outputting there, but src/lib is meant for source code and not generated output

Just tried that out, that does not work as far as I'm aware of.
On of the core problems is that we have multiple imports to $lib/paraglide/*, which we could technically rewrite to something like this ../../.svelte-kit/paraglide/*. But this looks pretty ugly and feels strange.

The other problem is that changing messages/en.json used to trigger HMR. After this change it does not. Not only that, but refreshing the page does not bring up the expected result. Only restarting the dev server brings up the result.

Same goes for stuff as ./node_modules/.cache/paraglide as far as i can tell.

[jackvanderbilt-visma]

I feel like the better solution would be to change outdir: './src/lib/paraglide' to something in .svelte-kit. I'm not that familiar with paraglide or what it's outputting there, but src/lib is meant for source code and not generated output

The other problem is that changing messages/en.json used to trigger HMR. After this change it does not. Not only that, but refreshing the page does not bring up the expected result. Only restarting the dev server brings up the result.

Paraglide should ideally implement a virtual module for translation files and utilize Vite's APIs to trigger HMR when needed, rather than writing files directly to the watched directory . That would remove the need for those files to be written to the filesystem entirely, which will improve build and dev performance too.

---

Sidenote: During my experience with webpack, I learned that the ~/node_modules/.cache folder is widely regarded as the go-to location for temporary files in the Node.js ecosystem. Unrelated but kinda to this issue; i think it would be great if SvelteKit adopted this folder instead of using ~/.svelte-kit. This change would help keep the root directory of a project clean and organized. I also store my ESLint and Prettier caches there, which has proven to be highly efficient—especially for speeding up GitHub Actions. Having the caches all in one place simplifies cache maintenance quite a lot. It would be fantastic if SvelteKit could configure caches there for Prettier and eslint automatically through the cli create command.

edit: (I just realized after writing this that I can probably configure the ~/.svelte-kit directory location, so I can choose to use the ~/node_modules/.cache folder myself).

[manuel3108]

@jackvanderbilt-visma Would you mind explaining why you closed the issue? I personally do think that this is still relevant

[AdrianGonz97]

Thinking on this a little more, this is actually related to #334 and #335 given that the eslint isn't including the contents of the .gitignore into it's ignore list. #335 (comment) should resolve this.

[manuel3108]

I don't think the linked comment will solve this, as we are not even adding ./src/$lib/paraglide to the gitignore at all. So this is still a separate issue in my opinion.

[AdrianGonz97]

that's because the .gitignore is added to src/lib/paraglide/.gitignore. it should be included in the root .gitignore instead, which would solve the issue

[manuel3108]

Ohhh, that makes sense. Yeah, that's the paraglide output that's generating that. Reopening for that fix.

[benmccann]

Agree with the Vite plugin suggestion. I'll file an issue in the paraglide repo about that

Just FYI, .svelte-kit is not a cache. It's intermediate build output. It's a build that you can run with pnpm preview. And if you build with an adapter it will do a second build using that output as source

[jackvanderbilt-visma]

@jackvanderbilt-visma Would you mind explaining why you closed the issue? I personally do that this is still relevant

My apologies! I was closing issues on this account because in the future I will no longer have access to it. This one was the only one I planned not to close as it was still relevant and useful to myself too.

[jackvanderbilt-visma]

Agree with the Vite plugin suggestion. I'll file an issue in the paraglide repo about that

Just FYI, .svelte-kit is not a cache. It's intermediate build output. It's a build that you can run with pnpm preview. And if you build with an adapter it will do a second build using that output as source

To me, the described intermediate build outputs sound exactly like something you’d typically cache 😅. However, since Svelte doesn’t hide these files from the user, they might not technically qualify as a “cache” by definition (see: definition of cache).

Are these intermediate build outputs something an end user would ever directly use? Or are they exclusively utilized or further processed by Vite or SvelteKit? If they’re essentially useless for the average Svelte user, I’d argue they should be moved out of the root directory. On the other hand, if they genuinely serve a purpose and users are likely to interact with them more often than I realize, I can understand why keeping them in the root might make sense.

Do I understand correctly that if it were to be that when you run pnpm preview svelte should do a fresh build (if one was not cached yet) and serve that one, the .svelte-kit directory no longer serves a purpose?

... now that I think of it, there is the .vercel folder that is expected by vercel... but maybe that path can be configured in the vercel.json too (which would be nice if the cli included by default, with good immuntable cache control headers preconfigured for static assets too btw)