Standalone vs non-standalone

[sveltejs]

Standalone vs non-standalone

[Rich-Harris]

I've been thinking it'd be good if the compiler had an externalHelpers: true mode that build tools could opt in to (i.e. you probably wouldn't want it for a standalone widget you were shipping, but it definitely makes sense for an app).

The same could apply to methods that don't differ between components, e.g. observe and the events stuff. (Though at that point you'd need to store callbacks under this, obviously.)

Basically, what Babel does – marking which helpers are used then either injecting them or importing them depending on the externalHelpers option. Progressive enhancement stuff would almost certainly fall under that category

[Rich-Harris]

Good catch, thanks – will add the fix to #219

[Swatinem]

It would be nice to have a mode that outputs just the generated code for dom manipulation (create, update, teardown), so the user can choose whatever state management library they would like (eg. mobx)

Not sure how that would best interact with nested components though.

[evs-chris]

Looking at progressive enhancement, I think it would be particularly useful to have a little bit of library code that could handle walking through the existing DOM to find a valid target and get it into the correct state.

[Rich-Harris]

Implemented as of 1.5.0 – build tool integrations will need to be updated to take advantage of it though

[Conduitry]

It looks like the built shared.js is not included in the 1.5.0 npm package that was published. I think the file needs to be added to the "files" section of package.json.

[TehShrike]

hmm, in my freshly-installed Svelte 1.6.0, I see a shared.js, but I don't see any of this new code in compiler/svelte.js. Did that file get updated/published incorrectly, or am I missing something?

[TehShrike]

Is there any technical reason why cjs modules couldn't be supported as well? Wouldn't

`const { ${names.join( ', ' )} } = require('svelte/shared-cjs.js')`

work as well as

`import { ${names.join( ', ' )} } from 'svelte/shared.js'`

?

[Conduitry]

Hm. Producing a shared-cjs.js would be as simple as adding a new Rollup config for the new built target. And having the Svelte compiler output different code for this depending on the format: option that was passed to it seems like a good idea.

As for your other issue, 1.6.0 is working fine for me with this. My compiler/svelte.js has all the new code supporting using the external shared.js.

[Rich-Harris]

@TehShrike

I don't see any of this new code in compiler/svelte.js

that's weird... it should be there, starting at line 6967 of https://unpkg.com/[email protected]/compiler/svelte.js. That not the case for your installation?

Is there any technical reason why cjs modules couldn't be supported as well?

Not really, though if we were doing cjs then we should probably do all the others, and that means treating them the same as other dependencies i.e. passing them in to the define call for AMD/UMD, etc etc.

And Svelte generates ES5, so couldn't use destructuring – would have to have a temporary variable and do var appendNode = shared.appendNode, etc...

And we'd need to have CJS and AMD and script tag builds of the shared helpers (or a UMD build).

So I looked at all those considerations and thought 'it's not worth the extra complexity' – since the only people who would be using shared helpers are using bundlers, and if your bundler doesn't natively support ES modules at the end of 2016 then it's probably time to find another bundler 😀

[TehShrike]

CJS modules

Fair enough. It's true, I can add es2015-modules-commonjs to babel, I just rarely need to. Not a big deal though.

1.6.0 published correctly

baaaaaah I see what was going on. I'd been reading the new code in #215 and was looking for references to "standalone" in the output code. I see now that it changed from "standalone" to "shared" in #219.