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
WIP(refactor(plugin-vite): better logic) #3583
base: main
Are you sure you want to change the base?
Conversation
This is not a mandatory PR to be merged, it's only for discussion. |
7fc7a19
to
23aca91
Compare
I still fail to understand why the default behavior you want is to copy everything and ignore specific things rather than the other way around. Please, try to help me understand why this is preferable when only a few modules actually need to be copied (or perhaps none at all, like in my project). Vite's default behavior is to bundle everything together and tree shake. What is the point of using vite if you are going to ignore half of what it does? Edit: if the answer is to avoid breaking changes, I would argue that we should make this breaking change, as it was done incorrectly to begin with. It would be better to right this wrong sooner rather than later, and save countless people in the future from bundling their app incorrectly. |
Regarding this implementation, I think I have two comments:
|
The first misconception is that not all If we exclude all |
Sorry, I keep saying "everything" when I mean "all dependencies". Dev dependencies will not be copied, of course.
Are you sure about this? My project is not configured to be an ES module and yet tree shaking works perfectly fine.
What exactly is the difference between a user knowing that they should ignore their dependencies and a user knowing they should specifically copy their native modules? Either way, a user has to know that they need extra configuration. Since native code is rarer, i do not think a default rule favoring it is preferrable, personally. Side-note: I will admit that I was previously unaware that are legitimate projects that put all their dependencies in devDependencies. There's apparently a line of thinking that all dependencies for a non-library are dev dependencies since the user does not need to install them and they are only needed for the build. I had not personally encountered this and based on my (admittedly limited) nodejs experience this is different from the norm. However, that seems to be more common in vite land? So while I might disagree with it, it is probably what vite users expect. I'm mostly just concerned about this due to the mismatch between the webpack plugin and the vite plugin. Maybe someone starting with the vite plugin would know to put all their dependencies into devDependencies because that's what vite people do, whereas a webpack user migrating to vite wouldn't. In that case, I would suggest a migration guide to help mitigate what I ran into, (which was wasting hours trying to figure out why it was bundling code i didn't want). At the very least, proper practice for ensuring your dependencies get processed properly should be documented. Anyway, I don't wanna be one of those guys who just relentlessly argues on the internet about something. So, I will not make any more comments on this topic as a whole except for making replies. I think whatever you decide to do is fine, and if it does not work for me and my project I can always just continue to patch the plugin. |
a517c24
to
34dc5a7
Compare
The main problem are things like |
And it's less of a PITA to manually blacklist? |
I usually rely on EDIT: It would perhaps be useful if |
Summarize your changes:
In flighting!
The main purpose of this PR is to solve the two issues currently encountered without breaking changes.
<7.2.0
and>=7.3.0
of Forge. (Undocumented breaking change for Vite plugin in v7.3.0 #3506)Users can configurepackagerConfig.ignore
to prevent plugin-vite from copying node_modules. (fix(plugin-vite): Don't copy node_modules on build #3579)dependencies
to node_modules of built App. (fix(plugin-vite): Don't copy node_modules on build #3579)~~