Support for 'svelte' field in package.json.

[antony]

Not sure if this is the correct place to raise an issue, but I'm sure it can be moved if not.

I've noticed that Snowpack's svelte support struggles if a package only has a svelte field, and is missing a main field. This makes me think that Snowpack is trying to use the main field for Svelte components.

Whilst this can be worked around, the ideal scenario is to respect the svelte field, since some packages (one notable example being Svelte Calendar) don't use a main field at all - https://github.com/6eDesign/svelte-calendar/blob/master/package.json#L3

The net result is a confusing error message about package-name/index.js not being found, even though that file isn't referenced anywhere. Addressing the component directly import Calendar from 'svelte-calendar/src/Components/Datepicker.svelte' also doesn't appear to work (simply produces a not found error). Meaning that the library is unusable with a Snowpack project.

[FredKSchott]

Oh interesting, we should be showing you a warning in this case about how to add support for svelte npm packages:

Failed to load XXXXXX
Try installing rollup-plugin-svelte and adding it to Snowpack (https://www.snowpack.dev/#custom-rollup-plugins)

Are you not seeing this?

[joshua1]

whilst this warning message exists , the link doesn't anymore on the latest snowpack website. Also been getting this error recently on a previously working app i am developing. installing rollup-plugin-svelte doesn't fix the issue

[m4rrc0]

I am struggling importing components as well.
I am relatively new to Svelte and still a little bit confused with the svelte field in package.json and how components need to be imported "from source" instead of being imported pre-compiled. It makes sense since the components can be compiled in many ways but I am not sure how Snowpack handles this. Does it only depends on rollup-plugin-svelte? Then the options we pass to the rollup plugin determine what gets built in the web_modules?

Part of the issue for me was that the rollup plugin didn't get passed the options. I have described the problem and solution here. But I am still struggling with some components and I don't really know if this is because of my config or because the library I am trying to import is poorly configured.

[FredKSchott]

Answered you in the discussion you linked.

Our plugin is definitely meant to work with all well-configured Svelte packages (although as mentioned in that discussion, SSR is still new and may have rough edges with this workflow). If you're seeing issues, it may be the package.

The best way to find out is create a simple reproduction. In the Svelte Create Snowpack App template, can you add an import for this package to use it?

[m4rrc0]

The best way to find out is create a simple reproduction. In the Svelte Create Snowpack App template, can you add an import for this package to use it?

Correct me if I am wrong but CSA only creates client-side apps with Svelte, right?

I can try on my next struggle but a working import on a client only Svelte app does not guarantee that it should work for SSR or any 'less standard' config. And there may be 3 reasons for that:

• Snowpack / Snowpack plugin / Snowpack config (which actually is 3 reasons on its own apparently, haha)
• 'exotic' developer setup (like the one I use for SSG concept)
• a misconfigured Svelte library and/or containing components not designed to support SSR (= avoiding window and such)

I will expand my answer in the other discussion because I have a feeling I am leading us off-track here. Sorry.

If we keep this discussion about whether or not Snowpack handles the 'svelte' field in package.json correctly, the suggestion to test with CRA is definitely a good start!
My understanding is that a misconfiguration may work in certain cases, for example if a pre-compiled Svelte component was compiled using the same config as we are.

What I am not sure of is... how to make sure Snowpack retrieves and compiles the imported component through the Svelte plugin?

Some discussions about Sapper mention

• having the libraries to be compiled in devDependencies instead of dependencies
• importing the .svelte file from 'inside' the library. (Ex: import Router from 'svelte-routing/src/Router.svelte' instead of import { Router } from 'svelte-routing')

I don't know what holds true with Snowpack.
From my experiments, none of these had any impact.
Neither did manually including the library with the install Snowpack config option for example.

[FredKSchott]

Yup, dependencies hit a special flow through that svelteRollupPlugin plugin that we were talking about in that other thread.

We just did some work to pass the dev Svelte compiler option, but I'd love a PR to pass all other svelte options as well, similar to what you proposed here: #1096 (comment).

[firefish5000]

Sorry for bumping this after a while, but I do not use rollup, just snowpack atm. I had to add

  installOptions: {
    "packageLookupFields": ["svelte", "module", "main"]
  },

to properly import svelte modules, else snowpack would not even look for a svelte field, and try main/module if it exist (and throw an error otherwise) which causes all kinds of hell for svelte. If you import svelte's compiled output into a svelte project, you get multiple svelte runtimes that do not play together.
I believe this should be added to the svelte and svelte+typescript templates (and possibly documented for those who do not use the templates. Though we could settle for having svelte document it like they already do for rollup/webpack)

[firefish5000]

Note this the above enough to make snowpack work with svelte packages installed from npm.
However, for some reason it wants rollup-plugin-svelte if you install a svelte project from the local filesystem.
That is to say, I have published @disposables/svelte-autobench and can install that from npm and use it with snowpack.
However, I cannot run npm i -D ../svelte-autobench and use snowpack, despite the fact it contains all the code that I published.
I... do not understand why that is being treated differently

[FredKSchott]

That packageLookupFields was just added in the last release, I agree that we can now make "packageLookupFields": ["svelte"] the default for the Svelte plugin. (module, main, etc are all already looked at by default).

Would love your help adding in a PR if you are interested!

[firefish5000]

I am having a hard time following the code. So let me explain the basics of what I fear may happen from what I think it will do.

we can now make "packageLookupFields": ["svelte"] the default for the Svelte plugin

This seems to imply that the plugin itself should set the field. I am assuming that if plugins add to that field, it pushes to it. that is, adding

packageLookupFields: ["svelte"]

to the svelte plugin itself would be the same as setting

packageLookupFields: ["module", "main", "svelte"]

in snowpack.config.js. In other words, I am assuming it will prefer main/module over svelte if both exist.
If that is the case, then this won't work. We need

packageLookupFields: ["svelte", "module", "main"]

to be the default.

Svelte sharable components should not use the main/module field when used in another svelte app. However, they actually specify both more often than not so that the component can be used in both svelte apps (using svelte field) and non-svelte apps (using the main/module field).

This means we need to prefer the svelte field over main/module. If this is already possible, then I may give writing the PR a shot. If not, I think specifying the order in the template is a much easier solution than trying to hack some sort of dependency resolution algorithm to packageLookupFields so snowpack plugins can inject things in smart locations.

[firefish5000]

Ok, after sleeping my ability to read vastly improved. Everything in it is prepended to the defaults. everything is fine.