As I noted in chat, I don't see why this is an issue. It seems like we could just inline these import { whatever } from 'svelte' statements, and avoid the dependence on svelte at runtime

yeah fair enough. removed. side-note — I was thinking that it probably makes sense to just use Rollup to create the standalone things (with everything except svelte considered external), rather than the current Heath Robinson nonsense

That sounds way saner than the current mechanisms for this, but I am a bit worried about the compiler's size. Am I going to be forced to download Svelte with a bundled-in version of Rollup? Am I going to be forced to install it as a dependency even if (for some reason) I don't want it? (Or if I already have a different/newer version of Rollup as a dependency of my app?)

Do we want to make Rollup an optionalDependency, and throw if we try to compile in standalone mode with it unavailable?

definitely a fair concern. also, it would force svelte.compile to become async. maybe we should cross that bridge later

Do we want to drop standalone component compilation as part of svelte.compile and introduce a separate function that does require Rollup, or maybe some sort of drop-in Rollup plugin or config?

One possibility would be to make this not svelte.compile's concern at all, and to take care of it in the component-template rollup.config.js.

I do see the value of no longer having to worry about this weirdness, but I am concerned that we will be stuck with it until Svelte v4 unless we do something as part of these changes.

I think we should strongly consider it. I don't think it needs to make it into this RFC (it doesn't need to cover every aspect of v3) but yeah, we should try not to lose track of it. Standalone components are a useful selling point of this framework but they are also a total bloody nuisance

Wait I just realized, this would also probably let us leave behind all of the non-ESM output modes too. Dang this is sounding real tasty now.

Ugh I just remembered the Svelte CLI which people are still using for some reason. I don't know how that fits into this anymore. Do we tell the people who were using it to create standalone IIFEs to get lost?

Do we want to have some naming/prefixing convention for built-in methods (or data, like the current options or root)? This is a little less easy to type, but it does avoid issues in the future if we want to add something and we need to figure out whether that's a breaking changing change because it might conflict with user-defined items. We can tell users 'don't name anything starting with a $' but we can't say 'don't name anything that sounds like we might want to use it later potentially'.

Not a bad idea. Vue does $ prefixes. As long as there's no point of confusion with Store, that's probably a good move

I don't understand why fire and on are removed?

A method's sole purpose may be to emit an event, and rather than pass the Component a props.onFoobar , something else can listen to Component for that sequence

const greet = new Greeter();
const stutter = str => str.charAt(0).repeat(3) + str;

greet.name = 'Bob';
greet.name = 'George';

greet.on('pretty-girl', stutter);

^ My concerns erased. Solved in chat.

As mentioned in chat, I would really like to see this be written as this instead:

<!-- ambiguous "preload" applies to both scopes -->
<script preload>
  export function preload({ params }) {
    //
  }
</script>

<!-- specify "preload" scope -->
<script preload="client|server">
  export function preload({ params }) {
    //
  }
</script>

We already have a "scoped" vocabulary around styles. Adding another instance of it, for scripts – with different meaning, would be bad IMO.

Another alternative, if one doesn't like the duplicate preload in such close proximity is to allow default export since we already know this is a preload-specific operation.

<!-- ambiguous "preload" == both -->
<script preload>
  export default function ({ params }) {}
</script>

<!-- OR, contextual "preload" -->
<script preload=client>
  export default function ({ params }) {}
</script>

<!-- OR, ambiguous attribute, specific functions -->
<!-- ... this might be problematic (for resolving dependency imports / tree-shaking?) -->
<script preload>
  export function client({ params }) {}
  export function server({ params }) {}
</script>

I actually think the unification of the different types of static stuff that can be attached to a component is nice - and being able to make preload just be a convention is great. (If we want to have different client/server preloads, could that just be part of Sapper's convention?)

That said, I am really not fond of the term scope='shared' that's being proposed to indicate this. I don't have a better suggestion currently.

I'm inclined to agree with @Conduitry — preload is an awkward anomaly. The less we have those special cases the more stable a platform for innovation the framework becomes

TBH I'm not sure what either of you are saying 😅

There's nothing special about preload — it doesn't have any defined behaviour. It's just a function that will get attached to both client and server components as a static method, and it gets that privileged treatment because Sapper needs it.

But ideally Svelte shouldn't have features that exist just for the sake of Sapper — someone with different opinions about how to build an app framework with Svelte should be able to do so.

This RFC, among other things, is about stripping Svelte down to its bare minimum — two methods instead of five, one way of making values available to the markup instead of (3? 10? depends which ones you count).

Since we need some way of including code that runs once per app (instead of once per component), we need to have the second <script> tag. Since we have that second script tag, we may as well use it for preload rather than it being its own special thing.

100% agreed - apologies if something I said pointed to the contrary. I was merely just renaming scope

Having extra script tags also allows new app frameworks to define new boundaries for new behaviors, especially if/when Svelte users are accustomed to having them already.

Ah ok, I thought you were implying that the second <script> was purely for preload. Certainly in the market for alternatives to scope

No, but in Sapper apps that would/could be the place for it... Standlone, hoistable preload functions that the Svelte compiler can rip out (safely) per-bundle-type and put those snippets wherever Sapper tells it to put them.

Svelte just needs to be aware of/handle more than 1 script tag

Not sure if I see the problem?

<h1>Hello, {{name}}!</h1>

<script>
  import { ondestroy } from 'svelte';
  import { Store } from './my-store';
  
  // setup code
  export let name = 'world';
  const store = new Store({ name });

  const listener = store.on('state', ({ current }) => {
    // something changed... changes this component's "name"
    name = Math.random().toString(36).slice(7);
    // this component now updates
  });

  // cleanup
  ondestroy(listener.cancel);

I think what that loses is being able to have the store Just Be There without having to manually import it in every component, with the different relative paths that will entail.

Perhaps we could use @TehShrike's <svelte:meta bind:XXX/> idea for this?

I'm not certain we want to maintain a magic way of referring to store properties in templates (the $-prefixed identifiers).

Personally I'd like to get rid of magical store presence. Not everything needs to connect to a/the store or have access to it.

Doing it this way also lets a develop to define a custom top-level store (or multiple) and import the ones they want within any given component.

As for $vars being accessible – I think that can still be achieved if we wanted to. If the compiler can link up foobar it should be able to link up $foobar too?

But, personally, I'd prefer to do away with magic $vars and have the store update the variables I've declared & wired up during setup. For example, the export let name being updated within store listener.

But, personally, I'd prefer to do away with magic $vars and have the store update the variables I've declared & wired up during setup. For example, the export let name being updated within store listener.

Strong disagree on this sentiment from me. We're using stores heavily and the ability for children to inherit parent stores and transparently reference $vars is super valuable to our sanity and iteration speed.

Fair 😆 For context, I use store in less than 10% of my components.

I'm with @tivac on this one.
The (relatively) simple & consistent (ie. same api) implementation of Store in v2 won a lot of people over imo - including me! By all means knock yourself out with other stricter store implementations etc but in some parts of the real world it is very useful indeed

Strong agree w/ @tivac and @tomcon on this one.

If we're using special prefix $ like @Conduitry suggested, this could just be $props which looks 10x better.

<Foo {...$props} />

<script>
  import Foo from './Foo.html';
  import Bar from './Bar.html';
    const subset = () => {
    const { thingIDontWant, ...everythingElse } = $props;
    return everythingElse;
  };
</script>

My idea with the $ prefix was that it was for externally-visible methods/data on the component instance. For making stuff available to code inside the component, I'm currently favoring something like @TehShrike's <svelte:meta bind:XXX/> idea over that of magic globals.