-
-
Notifications
You must be signed in to change notification settings - Fork 117
feat: log warning if svelte field causes difference in resolve #510
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 6 commits
ebe18d4
81bfa52
f8c856b
4a6f5f0
8335144
4468262
eb933fe
3f86ab0
63fe891
e24d839
c608797
8a46847
c66e2f5
d1e7e2d
4771880
13abab4
e1b1e6d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
--- | ||
'@sveltejs/vite-plugin-svelte': patch | ||
--- | ||
|
||
log deprecation warnings for packages that use the "svelte" field to resolve svelte files differently than standard vite resolve | ||
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -177,3 +177,32 @@ There is no golden rule, but you can follow these recommendations: | |||||
|
||||||
This warning only occurs if you use non-default settings in your vite config that can cause problems in combination with prebundleSvelteLibraries. | ||||||
You should not use prebundleSvelteLibraries during build or for ssr, disable one of the incompatible options to make that warning (and subsequent errors) go away. | ||||||
|
||||||
<!-- the following header generates an anchor that is used in logging, do not modify!--> | ||||||
|
||||||
### deprecated "svelte" field | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. per @dummdidumm's point, I'm not sure we need to actually deprecate the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i don't think we can recover from a resolve error unless we always call There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's already two ways to resolve JS files with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can we change the title from
I agree with what you said in that comment and so the word "deprecated" seems too strong to me There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dominikg any thoughts about the heading title here? I think it might be the only outstanding item for us to resolve There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
i have changed the wording to use conflicting resolve results instead of deprecation. |
||||||
|
||||||
In the past, Svelte recommended using the custom "svelte" field in package.json to allow libraries to point at .svelte source files. | ||||||
dominikg marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
This field requires a custom implementation to resolve, so you have to use a bundler plugin and this plugin needs to implement resolving. | ||||||
Since then, node has added support for [conditional exports](https://nodejs.org/api/packages.html#conditional-exports), which have more generic support in bundlers and node itself. So to increase the compatibility with the wider ecosystem and reduce the implementation needs for current and future bundler plugins, it is recommended that packages use the "svelte" exports condition. | ||||||
dominikg marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
||||||
Example: | ||||||
|
||||||
```diff | ||||||
// package.json | ||||||
- "svelte": "src/index.js" | ||||||
+ "exports": { | ||||||
+ "./package.json": "./package.json", | ||||||
bluwy marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
+ "./*": { | ||||||
+ "svelte": "./src/*", | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. does this need to be this...
Suggested change
...in order for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ideally it would be 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) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think Rich's suggestion is the correct way to support it. Using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. removed the glob example and linked to the other faq entry. |
||||||
+ }, | ||||||
+ ".": { | ||||||
+ "svelte": "./index.js" | ||||||
+ } | ||||||
} | ||||||
``` | ||||||
|
||||||
> **Support for the svelte field is deprecated and is going to be removed in a future version of vite-plugin-svelte.** | ||||||
> | ||||||
> Library authors are highly encouraged to update their packages to the new exports condition as outlined above. Check out | ||||||
> [svelte-package](https://kit.svelte.dev/docs/packaging) which already supports it. |
Uh oh!
There was an error while loading. Please reload this page.