-
Notifications
You must be signed in to change notification settings - Fork 10
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
Does meteor-vite ignore package.json#imports by default, or is meteor-tool trimming wings? #231
Comments
Tracing the issue found in With official term |
This exact case is also brought up here: https://www.npmjs.com/package/resolve.imports#subpath-imports |
Seems to be unclear whether this is active, though allegedly merged: For the record I am using |
So far have tried |
Since the only package involved for right now is |
Oh, interesting. Never heard of this convention before. If they're saying it's fixed, there shouldn't be anything preventing Meteor-Vite from working with it. If you're on Meteor v3, you can safely update Vite to v5 to give it a try. 👍 There is one caveat however, the Meteor server does not take your Vite configuration into consideration when compiling. So, unless you're also building the Meteor server with Vite using the Otherwise, you can define your import aliases with a |
Thanks very much @JorgenVatle; I will try And you had advised You brought up a burning question of mine: Does |
When using the The process is more or less the same for the client. Unless you're using the Meteor-Vite v3 pre-release which entirely skips Meteor's build process for client assets. They are all built by Vite and then served as static assets by Meteor in production. The server will always need to be passed through Meteor's build system though. |
When building for production, you should see some messages from Vite logging out the build process. If Vite isn't being used to build for production, you'll likely find that the build fails. |
Thank you for demystifying that >80% @JorgenVatle, that is much clearer. I seem to be in a good position to leverage the best aspects of Will check back once I get this solved and mention the solution. It seems like people specifically mention Making a lot more sense! I value these early difficulties to be able to understand the innards much better. Thanks again! |
Side question here, and please let me know if this is better off as a separate issue; this is at pre-insanity for me right now: How hard would it be to add more entry points? Would LOVE to have an infinite number of Right now I have three+ separate build environments in an omnirepo, but it really should be one codescape with many mire tree-shaken entry points. If I could have |
Notes here: https://forums.meteor.com/t/how-to-make-meteor-unignore-package-json-imports-inside-dependencies/62493/1
package.json#imports
seems ignored in at least one case, but in looking at that convention... wow would I love to use that instead of setting aliases in three places.Thought to ask the solo ninja wizard around here while pursuing this. Please let me know if there is a better place for issues which start out as questions but might turn into items to resolve if there is a problem.
The text was updated successfully, but these errors were encountered: