chore: move create into its own package

[AdrianGonz97]

This PR moves the template creation logic into it's own package create, rather than having it live directly in the sv package. This will allow us to separately publish this package so that outsiders can use it's programmatic api via @svelte-cli/create (without needing to have a direct dependency on sv).

After this is merged, we can start adding the commands and move it's usage into sv init (or sv create), rather than its current form of emulating how it used to work in svelte-add.

[pkg-pr-new]

commit: 0cc1d56

pnpm add https://pkg.pr.new/sveltejs/cli/@svelte-cli/ast-manipulation@8

pnpm add https://pkg.pr.new/sveltejs/cli/@svelte-cli/ast-tooling@8

pnpm add https://pkg.pr.new/sveltejs/cli/sv@8

pnpm add https://pkg.pr.new/sveltejs/cli/@svelte-cli/core@8

Open in Stackblitz

[Conduitry]

Will changes to @svelte-cli/create automatically result in releases of sv pinned to that version as well? (Or perhaps with that new version bundled?) If sv has a semver range dependency on @svelte-cli/create, then I wouldn't want to rely on npx sv pulling down the newest version of @svelte-cli/create if it had already been run in the past.

[AdrianGonz97]

Will changes to @svelte-cli/create automatically result in releases of sv pinned to that version as well?

If we apply it as a dependency of sv (atm, it's a devDep on @svelte-cli/core for reasons of just getting it in place for now to match the old svelte-add behavior), then changesets should increment sv's version any time @svelte-cli/create's version updates. We'll also have it pinned to use exact versions using workspace:*. This should provide a consistent experience across repeated* runs.

then I wouldn't want to rely on npx sv pulling down the newest version of @svelte-cli/create if it had already been run in the past.

yea, we've had trouble with this in the past and are avoiding semver ranges on most of our own dependencies that aren't bundled

[benmccann]

I'm find with moving create into its own package for organization purposes, but I was sort of hoping to bundle all of our dependencies to avoid publishing any new packages besides sv. Can we export create from sv? That would also allow the possibility for create to setup various integrations in the future

Also, fwiw, neither @Conduitry nor myself are aware of any specific users actually calling create. I expect there are at least some, but not necessarily any big important ones

[AdrianGonz97]

I'm find with moving create into its own package for organization purposes, but I was sort of hoping to bundle all of our dependencies to avoid publishing any new packages besides sv. Can we export create from sv? That would also allow the possibility for create to setup various integrations in the future

Bundling gets a tad annoying when create has it's own assets that need to be copied over from the dependency into the new dist.

I think it's a bit easier and more convenient for us to go down the route of just having a dedicated package for this in an effort to avoid others having to download unnecessary dependencies (like all the heavy ast tooling) if they're forced to use sv just to access create. Sorta similar to the recent efforts splitting package-manager-detector into it's own package from ni

Also, fwiw, neither Conduitry nor myself are aware of any specific users actually calling create. I expect there are at least some, but not necessarily any big important ones

we use it directly for the Skeleton CLI - usage site

[benmccann]

I feel like it won't be a great experience for skeleton users that they won't get all the other setup questions. There's no way for them to setup testing, formatting, linting, etc. during initial project creation if create is a separate project that they call. Maybe the skeleton CLI should be an adder instead?

[AdrianGonz97]

I feel like it won't be a great experience for skeleton users that they won't get all the other setup questions. There's no way for them to setup testing, formatting, linting, etc. during initial project creation if create is a separate project that they call.

ah, all good points. alrighty, I'll set it up to be bundled instead

edit: actually, it'll be better to set that up once it's a direct dependency of sv instead of core. that can be done separately

edit 2: i've tweaked it such that create is now bundled with core (once we get the sv create command in place, we could bundle it directly into sv instead)

Maybe the skeleton CLI should be an adder instead?

we definitely tried back when svelte-add was still using git submodules 😆 but yea, it would be better suited as a community adder once we've got that ready

[manuel3108]

As others have suggest I would also prefer to have all the commands bundled into sv.

IIRC we intended to call the command sv init to create a new app. Should we also call the bundled package init then to keep it clear?

Edit: Other than that everything looks good

[dominikg]

why sv init and not sv create ?

[AdrianGonz97]

IIRC we intended to call the command sv init to create a new app. Should we also call the bundled package init then to keep it clear?

I keep calling it create out of habit because of npm create. however I do prefer it as it's name is clearer in purpose and feels more natural to me. if everyone thinks sv init is better, we can certainly rename the package to init

[manuel3108]

I'm fine with both, we could actually also implement an alias just in case.

Some references:

• npx nuxi init
• npx vue create

Others use npm init whatever, but I have not included them above, as this will not apply here. Seems we have both across the different tools

[dominikg]

i think the svelte community is more used to create, but npm itself also aliases it, so maybe both isn't the worst?

[benmccann]

I'll do a poll of the ambassadors to see if there's any clear naming preference

[benmccann]

I would have chosen init as being shorter, but was widely outvoted 😆 So I guess we should go with create

[benmccann]

edit 2: i've tweaked it such that create is now bundled with core (once we get the sv create command in place, we could bundle it directly into sv instead)

Yeah, I feel like we should probably avoid bundling it with core. I think of core as utilities to build adders, and probably community adders will need to depend on core, but won't need all the templates. Bundling it with sv makes sense to me. I don't have an opinion on whether that means it lives in the cli package or its own