New project creation template should include sv in devDependencies

[benmccann]

No description provided.

[manuel3108]

Should it? Didn't we decide against this at some point? Especially with #39 and they way we implemented that, does this still makes sense?

[benmccann]

This is what folks were suggesting at the maintainers meeting I believe - though I didn't have clear thoughts on it personally. I guess the benefit would be that you could control the version of sv you're running as compared to running the latest. I suppose if you're on an old version of SvelteKit maybe that lets the adder work better. It'd also help with discoverability and promoting the tool to have an sv command in the package.json. The part I was a bit worried about was that it would create churn in your package.json to have to update it whenever you want to run it. At least at the moment it's something you'd run pretty infrequently, but maybe that changes if we have it scaffold individual routes or something.

I don't think #39 would prevent us from doing this

[manuel3108]

Agree, this has nothing to do with #39.
As long as it's not necessary i would avoid it.

[AdrianGonz97]

I'm unsure if it's a good idea, but I'm still open to it

If we're doing this though, then I think #35 would be necessary to ensure users are always up-to-date. Ben's idea of only having it check for updates on add would be a fair compromise too (migrate and check shouldn't ever care about what version of sv they're on)

---

Here's an alternate idea: what if we just include a script to invoke in their package.json instead?
ex:

{
	...
	"scripts": {
		...
		// (the PM can be adjusted based on what they used to scaffold the project)
		"sv": "npx sv@latest"
	}

upsides:

• it lets sv be a bit more visible
• they get to use it as if it's a local package with pnpm sv add ...
• it'll always be up-to-date

downsides:

• startup times will be a bit slower as the package version needs to be validated
• doesn't really help npm users since they'll need to use npm run sv
• the output isn't guaranteed to be repeatable since they're always getting the latest version

to address the last downside, maybe pinning it to the major could work?

{
	...
	"scripts": {
		...
		"sv": "npx sv@1"
	}

thoughts?

[manuel3108]

i kinda like this idea tbh

[benmccann]

If you do npx sv@1 I'm not sure you'd always get the latest v1. I imagine that it could return a prior version of v1 it finds in the local cache and still be satisfying the condition. Different package managers might do different things there

If we did install it into the project, it does seem quite annoying to have to do npm run sv add, get a warning that you're not on the latest, quit, upgrade, and then run again. I wonder if you could ask the user if they want to upgrade, and then upgrade and automatically invoke the newly downloaded version via package-manager-detector so that it feels more seamless.

[Conduitry]

What, specifically, are we thinking the user would want to do with an existing project with a specific version of the CLI? I'm definitely finding myself preferring not including this as a dev dependency, if at all feasible.

[benmccann]

I think there were two motivations. One was that if you want to do something like npm run sv check then you don't necessarily want to hit npm to be able to do that. The other was that maybe we wouldn't have to support multiple versions of Svelte or SvelteKit within an adder as folks on older versions of the framework could stay on older versions of sv. But at least for the adder case it does feel quite awkward to install the CLI into devDependencies.

Another idea might be to have sv be just a tiny wrapper that invokes other CLIs and to have a @sveltejs/add that sv invokes via npx. Then you could still have sv check work without hitting npm and would rarely have to bump the version. Folks on older versions of Svelte or SvelteKit could provide a particular version they want to run

[manuel3108]

I think, we should leave this as is as a standalone npx command for now and wait for feedback.