CLI suitable for more real use

[kylecordes]

Currently the svelte CLI command "is useful if you want to try out Svelte, but it's not recommended for serious production use", per the documentation. The documentation further wisely recommends adding a bundler and various other tools for real use.

This advice and approach is great for many bases, but Svelte is very well suited to a certain kind of modest use, adding just a little bit of JavaScript widget interactivity to an existing application/site/etc. Yet when doing so, following the advice above, you end up spraying numerous additional dependencies into the target project, for just the most modest small use. Thus it is required a few amount of project-level change to add the first tiny Svelte component.

Therefore, a feature idea:

Expand the CLI to use rollup, plug-ins, Babel, etc. to emit reasonably production grade output for simple to moderate use cases, suitable for use with a wide range of browsers, etc. - with just a single dependency, and perhaps one package script with a few commandline switches. (Advanced uses cases and configuration would still require separately depending on and configuring many tools, of course.)

Such a feature would make it easier to adopt a tiny bit of Svelte, easier to get the camel's nose under the tent, so to speak.

(This also might be a terrible idea; because it might lead to expectations for a CLI comparable to those popular with React Angular Vue and other projects that have a broad contributor community among which to spread the work of maintaining such a beast.)

[Conduitry]

The main issue with this (since the CLI is part of the main svelte package now) is that if we added any of this stuff to the main CLI, it would greatly increase the download size for people who don't need any of these features.

I'm mostly ambivalent to whether there should be an all-brands-of-batteries-included CLI, but if there is, it should be a separate package.

[Rich-Harris]

A possible half-way house: the CLI could have extensions that are installed separately:

$ svelte compile --fancy Input.html > Input.js
You must install the fancy extension to use the CLI in fancy mode. Would you like to do that now?
> y
[installing...]

That way we keep the CLI itself nice and lean, we get to keep the package name the same as the name of the executable (great for npx), but can add whatever wacky features we like.

[kylecordes]

On one hand I share that ambivalence about whether a powerful CLI is a good idea, versus a set of tools composed per project.

On the other hand, looking around, the platforms that have successfully attracted large user and contributor communities have mostly (or all) landed on "have a feature rich CLI that does a whole bunch of things right by default". Of course, I also don't know whether attracting a bigger community is a goal of Svelte.

[kylecordes]

(about the packaging thing: yes certainly if a CLI of considerable functionality were to grow, it should be split out from the core package.)

[Rich-Harris]

This issue has become more important with the advent of v3. Previously, it was possible (in fact it was the default) for components to be compiled in standalone mode, whereby all the internal helpers used by the component would be inlined into the resulting module.

This had two major downsides...

• it was much too easy to end up duplicating code in a Svelte app, and gave people the wrong impression about how their apps would scale
• it added a huge amount of complexity to the compiler

...and is no longer the case in v3. Internal helpers are always imported from svelte/internal.mjs.

So, whither the CLI? In its current form it is essentially useless. It doesn't create code that will run in any browser, unless you serve node_modules/svelte and provide the correct sveltePath option, which involves expertise we shouldn't expect from casual users dipping their toes in (the CLI's primary audience).

The initial proposal above is one possibility — making it advanced enough that you can use it to bundle a Svelte app. But that would add an awful lot of bloat and complexity to the svelte package (if it contained the CLI), and in any case 'advanced enough' is something of a moving target. For production use we're always going to recommend integrating Svelte into a dedicated build setup (even if it's an off-the-shelf one), so it seems perverse to go to so much trouble to build and maintain something that is intended not to be used except for the first five minutes.

My half-way house proposal doesn't really fix things either — since you can't do anything without installing all those extra packages, you're really just adding confusion and complexity to the unboxing experience.

I think my preference therefore is to remove the CLI from svelte (and maybe maintain a separate svelte-cli or create-svelte-app package, though we'd need to figure out what was in scope. I can certainly see one of those being a popular way in, since manually configuring bundlers is becoming somewhat unfashionable these days).

Thoughts?

[kylecordes]

Based on the experience of numerous other broadly similar tools, it appears that the technical and ecosystem forces strongly agree with your preference, Rich. A CLI is better off as a separate package, not inside the core runtime package

(Incidentally, there is also a movement away from FOO, FOO-cli, create-FOO-app etc packages, toward “@FOO/core”, “@FOO/cli”, etc. Maybe that ought be considered here also.)

[arxpoetica]

I'm also in the camp of separate cli (if any). Remove it.

[antony]

Closing since the cli as discussed doesn't exist any more, and there are different discussions about an actual CLI.