esinstall can't import Svelte component libraries with JS entry point

[Rich-Harris]

Repro here: https:/Rich-Harris/esinstall-repro

If a project imports a Svelte component from npm, where the "svelte" field in package.json points to an individual component, esinstall copies the component across untouched.

But if "svelte" points to a JS module (which is totally valid — the module in turn imports Svelte components), esinstall will attempt to install it.

In the best case scenario, this results in a compiled component in web_modules, but because it bundles svelte/internal, it will fail in many apps (since svelte/internal essentially needs to be a singleton — it's no good to have first-party and third-party components controlled by separate schedulers). It also fails in SSR, because it is compiled as a CSR component by default.

In the worst case scenario, esinstall hangs for a while before the process runs out of memory and crashes. I haven't been able to figure out why this happens, but I know when it happens — components with <style> (which result in a .css import being added) cause this behaviour. This is the case for @sveltejs/pancake, for example.

Ideally, .svelte files and other non-JS assets would be excluded from the installation process, for later processing by Snowpack. Is that possible?

[FredKSchott]

esinstall uses Rollup internally, so you can add Rollup plugins to customize esinstall's package install process. @snowpack/plugin-svelte automatically adds the https:/sveltejs/rollup-plugin-svelte plugin when Snowpack runs esinstall internally:

const svelteRollupPlugin = require('rollup-plugin-svelte');

// Support importing Svelte files when you install dependencies.
snowpackConfig.installOptions.rollup.plugins.push(
  svelteRollupPlugin({include: '**/node_modules/**', compilerOptions: {dev: isDev}}),
);

installOptions is what gets passed to esinstall, so you could do the same via the esinstall rollup option.

[Rich-Harris]

The issue is that I don't want components to be compiled during installation; I want them to be left alone. At the moment the Svelte plugin compiles them automatically. But if that plugin is removed, esinstall fails because it encounters non-JS files. Unless I'm missing something?

[Rich-Harris]

(To be clear I don't think this is a Svelte-specific issue, this would apply to any package that imported non-JS files in the expectation that they would be handled by a later dev server or build step. I think it would be enough for esinstall to just bail out of the bundling optimisation as soon as it hit a file it wasn't set up to process.)

[FredKSchott]

Okay, I spent some time digging into this and found a bug in our current "compile at install time" flow. Going to focus on getting that back to working first (which would get your repro repo working) and then can take a look at this.

Snowpack's install process was designed to bundle packages of many files into one JS file (@sveltejs/pancake -> @sveltejs/pancake.js) which currently requires compiling & bundling Svelte at install time. Svelte might be the exception here, and I'd love to get these raw .svelte files running through the main unbundled build pipeline. But it would be a bit of a departure conceptually.

[betaboon]

We seem to be running into this exact issue with TheComputerM/svelte-materialify#132.
So I wanted to ask if there has been any progress on this issue or if there is a known workaround.

maybe @Rich-Harris has something to share ?

[dimfeld]

I was seeing the same performance issue today importing the layercake package, on a project which previously worked. I believe this just broke with 2.18.

Using snowpack 2.17.1, which includes esinstall 0.3.7, I am able to import from the package, but with 2.18 I see the same behavior that Rich encountered, where esinstall uses a lot of CPU and eats up all the heap until it OOMs.

[antony]

I've just tried this importing svelte-simple-autocomplete with snowpack 2.17.1, and "installing dependencies" never completes, it just spins up my fans forever until a huge OOM stack trace appears.

svelte-simple-autocomplete doesn't actually use a barrel import, it just specifies a regular Svelte component as the svelte entrypoint.

This also happens with snowpack 2.18, and FWIW, 2.16

[FredKSchott]

Ah you're right, this looks like a regression. PR is up to fix in #1908

[fabien]

This still appears to be an issue with ‘barrel’ imports, which is how many component libraries are packaged.

@FredKSchott @Rich-Harris thoughts?

[fabien]

Cross-posting since discussions don't pick up referenced issues:

TheComputerM/svelte-materialify#113 (comment)

[FredKSchott]

Update (/cc @fabien @Rich-Harris) Confirmed repro is fixed in #2707