Nested async components error when switching components

Describe the bug

When nesting dynamic components that are imported via await import('/SomeComponent.js'), when the top-most component class is changed, the following error is thrown.

Logs

TypeError: undefined is not an object (evaluating 'outros.c')

(full traceback below)

To Reproduce

I was unable to reproduce this in the REPL (I assume it doesn’t support dynamic imports), so here is a repro repository: https://github.com/taylorzane/svelte-async-import-repro

Just run yarn build && yarn start and then open up the webpage and attempt to click the button. It will switch the to-be-imported component from Child1 to Child2 (both of which dynamically import SubChild)

Expected behavior

The component switch/transition should not throw an error.

Stacktraces

Stack trace

[Error] Unhandled Promise Rejection: TypeError: undefined is not an object (evaluating 'outros.c')
	transition_out (Child1.js:150)
	o (Child1.js:603)
	transition_out (bundle.js:165)
	p (bundle.js:358)
	p (bundle.js:455)
	update (bundle.js:126)
	flush (bundle.js:100)
	promiseReactionJob

Information about your Svelte project:

• Your browser and the version: Safari 12.1.2

• Your operating system: macOS 10.14.6

• Svelte version: v3.9.1

• Rollup

Severity

Currently makes multi-page (sapper) svelte usage entirely unusable.

Additional context

Might be related to #3165, but seems slightly different (outros is definitely defined)

[ghost]

If I understand what everyone here means by “dynamic components” as “components built from a separate Svelte project, of which the final JS file is dynamically loaded” then the reason for these errors is because Svelte bundles with its own copy of the runtime internals (or rather, by default that’s what bundlers do with Svelte).

I’m making this assumption because otherwise you would just download the .svelte files and include them in your project like usual, in which case they would get bundled with the same internals as the rest of your project anyway, and the OP gave the example of import()ing a .js file.

Unfortunately if this is the case then any suggested fixes relating to guards etc. only half-fix the problem because there are still incorrect state tracking variables lying around which could cause more problems later on, even if no errors are thrown.

The runtime internals use module level variables to track state, so when a component from one project calls a component from another project and both use their own copies of the internals things start going wrong due to the state tracking variables not being shared.

I started an issue specifically about this here: https://github.com/sveltejs/svelte/issues/3671

In the end @halfnelson came up with a solution where the pre-built component should declare at least the svelte/internal imports as globals (rollup) or externals (webpack).

You can see that comment and my comment afterwards stating what I did here: https://github.com/sveltejs/svelte/issues/3671#issuecomment-541277465

If this is the problem that’s being discussed here then it would seem that projects distributing pre-built Svelte components should set their bundles to be built expecting at least the svelte/internal import to be provided as a global somewhere.

In the case where they want both the option to be imported into an existing Svelte project or be used as a standalone component in a non-svelte project (in this case they would need their own internals) then they could set up the build to use globals if they exist or their own copy if they don’t exist. I haven’t looked into how to go about doing that myself though.

If that’s not possible then a project distributing pre-built Svelte components could provide two builds quite easily; one that contains a copy of the internals and one that expects them to be available somewhere in the environment, like as a global. The one that expects the internals to be available somewhere in the environment is the one that would be used inside a Svelte component built as a separate project.

The only downside to this is that if the components were built using different versions of Svelte then it’s possible that the expected functionality of each component will go out of sync due to API changes. This is one of the trade offs you have to make when you decide to include a pre-built component into your project anyway though.

[sudomf]

Hey guys, any update on that? I’m experiencing the same problem with simple components in an if-else block.