refactor!: remove resolvePackageEntry and resolvePackageData APIs#14584
refactor!: remove resolvePackageEntry and resolvePackageData APIs#14584
resolvePackageEntry and resolvePackageData APIs#14584Conversation
I guess it's #12957 (comment). |
patak-cat
left a comment
There was a problem hiding this comment.
Sounds good to me! You're really pushing hard to clean up things in Vite 😄
It would be good to see what Anthony thinks given that it affects sli.dev though. And I wonder if Vite should export similar utilities in the future (once optimizations are done and you are happy with the new API). It seems useful for plugins to get the exact same handling of package.json as Vite and also take advantage of the cache.
Co-authored-by: 翠 / green <[email protected]>
|
Yeah once this is unblocked we should be able to refine the API to be public again for sure 👍 (especially the |
|
I think we can hold off merging for now and get qwik and slidev migrated first. |
|
Out of curiosity, is there a detailed explanation of the optimizations blocked by this API, the bugs caused by it, and how removing it will fix them? From a quick look, I have no packages depending on the API. |
|
|
I've sent the PRs upstream to remove them. Will go ahead and merge this. |
Description
They are preventing caching optimizations that we can do. IIRC the
setResolvedCacheAPI isn't correct too and is causing bugs. (have to find the issue#12957 (comment))Additional context
After a lot of yak shaving, I finally got to what I wanted to do!
Admittedly I didn't plan this ahead since it would be better with a deprecation phase, but I think it's fine as these APIs are rather internal.
GitHub search for resolvePackageEntry and resolvePackageData usage
Unfortunately
resolvePackageEntryaffects some Vite plugins, andresolvePackageDataaffects two big projects:qwikandslidev. But their usage are simple enough that the migration guide should work.What is the purpose of this pull request?