feat: log warning if svelte field causes difference in resolve

[dominikg]

fixes #501

• add documentation and update log message to contain link
• ensure svelte-package works with svelte exports field
• ensure we have enough documentation / recommendations for how to structure exports maps in svelte libraries, accounting for hybrid libraries and ssr as well.

1. do we need an option to disable these warnings
2. should they be logged upon encountering them or batched in buildEnd
3. how do we test this

[dominikg]

example warning

11:46:09 AM [vite-plugin-svelte] DEPRECATION WARNING: e2e-test-dep-svelte-nested@1.0.0 package.json has `"svelte":"src/index.js"` which resolves .svelte files but standard vite resolve failed to resolve.
Using the "svelte" field in package.json is deprecated and packages should use the "svelte" exports condition instead. See :LINK HERE: for more information.

[benmccann]

per @dummdidumm's point, I'm not sure we need to actually deprecate the svelte field. we just need to stop resolving it before exports and resolve it after instead. that would make the warning trigger less frequently which would be nicer for users

[benmccann]

actually, I just looked at the code and I think it works assuming the svelte field will be left in place and only changes the order. if we really did want to get rid of it entirely we'd probably have to change the code, but I'd just suggest changing the title here and note below saying it will be removed and instead say the resolve order will change

[dominikg]

i don't think we can recover from a resolve error unless we always call this.resolve in a try/catch not something i want to do long term.

[dominikg]

also having 2 accepted ways to do this doesn't feel great. it makes writing new bundler plugins even more challanging. The only point i see in this whole excercise is that at the end of it the svelte field is no longer used at all.

[benmccann]

There's already two ways to resolve JS files with main and exports, so it's just the analogous thing. As long as we prefer exports we can rip out all the code in vite-plugin-svelte and just defer to Vite

[dominikg]

@bluwy iirc you changed the behavior of exports + mainfields lately. Is the above still true? If yes we should be able to remove the custom code for resolveViaPackageJsonSvelte even today.

[benmccann]

can we change the title from deprecated "svelte" field to something more neutral like prefer "svelte" export condition over "svelte" field?

kept the svelte field as neutral instead of remove. We should not encourage them to remove it for now as that could break older tooling that still relies on it

I agree with what you said in that comment and so the word "deprecated" seems too strong to me

[bluwy]

If exports is define, Vite should ignore mainFields (except browser) completely now. Vite also doesn't have a restriction on what the extensions for mainFields could be, so exporting a Svelte component is fine too.

[benmccann]

@dominikg any thoughts about the heading title here? I think it might be the only outstanding item for us to resolve

[dominikg]

@dominikg any thoughts about the heading title here? I think it might be the only outstanding item for us to resolve

i have changed the wording to use conflicting resolve results instead of deprecation.

[Rich-Harris]

does this need to be this...

Suggested change

	+ "svelte": "./src/*",
	+ "svelte": "./src/*.svelte",

...in order for library/src/Foo.svelte to be importable as library/Foo? Or is that undesirable/ (Would that pattern even work?)

[dominikg]

ideally it would be "./*.svelte":{"svelte":"./src/*.svelte"} but that didn't work in my testing even though node docs show a similar pattern for *.js

omitting the extension altogether might confuse tools that look for it and may cause problems when there is a foo.js and a Foo.svelte (hello windows)

[bluwy]

I think Rich's suggestion is the correct way to support it. Using "./*.svelte" means they have to import as my-lib/Foo.svelte

[dominikg]

i'm not an expert on building sane exports map for a new custom condition, so definetely up for improvements. Unfortunately i couldn't make the case with .svelte in the condition work, would love for someone to show a working example.

[dominikg]

So what does an ideal svelte exports condition look like today? just exporting the index.js that lists all .svelte files? Or use a glob too so that deep importing components can work?

I'd love to have a guideline for package authors here. Prebundling has made it less needed to use deep imports but they can still be a valid choice.

[dominikg]

@dummdidumm @Rich-Harris

ideally this faq entry contains an example of a svelte exports map that works for most/all library authors. Once we merge this PR and they start updating, many are going to have to do a breaking release. If we change the recommended setup again later that would be kind of a d*ck move and put extra pressure on the whole ecosystem by introducing multiple major updates.

Any thoughts on how glob exports should be utilized if at all?

[benmccann]

I've never seen anyone use glob exports in the wild before. It's probably not a good practice. E.g. if you have a main component that uses a few sub-components, you probably don't want to export the sub-components. I think I would change the example to not use glob exports

In terms of index.js vs deep package path, I don't know if we're wanting to make a universal declaration on that yet. You could potentially show both examples and then link to https://github.com/sveltejs/vite-plugin-svelte/blob/main/docs/faq.md#what-is-going-on-with-vite-and-pre-bundling-dependencies for a deeper discussion of what method to choose

[dominikg]

Hadn't thought about internal subcomponents. But i do think we have to provide guidance on how to allow deep imports and/or index imports.

svelte-package stopped generating deep exports into package.json so it would be the library authors task to remember to add new components to that. But maybe thats preferable because with glob exports everything matched by the glob is public and that makes it easier to accidentally do a breaking change without realizing.

[dominikg]

removed the glob example and linked to the other faq entry.

[dominikg]

I have updated the PR to latest main and refactored it to log at buildEnd.

The new log output looks like this:

11:03:00 PM [vite-plugin-svelte] WARNING: The following packages use a svelte resolve configuration in package.json that is going to cause problems in the future.

e2e-test-dep-svelte-exports-simple@1.0.0

Please see https://github.com/sveltejs/vite-plugin-svelte/blob/main/docs/faq.md#deprecated-svelte-field for details.