Skip to content
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

Open
digitalextremist opened this issue Nov 2, 2024 · 11 comments

Comments

@digitalextremist
Copy link

digitalextremist commented Nov 2, 2024

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.

@digitalextremist
Copy link
Author

digitalextremist commented Nov 2, 2024

Tracing the issue found in Vite and mentioning my case specifically: vitejs/vite#7385 (comment)

With official term subpath imports https://nodejs.org/api/packages.html#subpath-imports

@digitalextremist
Copy link
Author

This exact case is also brought up here: https://www.npmjs.com/package/resolve.imports#subpath-imports

@digitalextremist
Copy link
Author

digitalextremist commented Nov 2, 2024

Seems to be unclear whether this is active, though allegedly merged:

vitejs/vite#7770 (comment)

For the record I am using Vite version 4.5.2

@digitalextremist
Copy link
Author

So far have tried @rollup/plugin-node-resolve and vite-tsconfig-paths and changing tsconfig.json values to no avail

@digitalextremist
Copy link
Author

Since the only package involved for right now is chalk and there is a lot of fog on this issue, I am bypassing color in logs very sadly and marking to return to this.

@JorgenVatle
Copy link
Owner

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 serverEntry config option, you will have to make sure Meteor also supports the convention, if you intend to use the aliases in code that's accessed by the server.

Otherwise, you can define your import aliases with a .babelrc config file, which is processed by Meteor. https://www.npmjs.com/package/babel-plugin-module-resolver

@digitalextremist
Copy link
Author

Thanks very much @JorgenVatle; I will try Vite 5 since I am using Meteor 3 and will check if chalk and package.json#imports works with that.

And you had advised babel-plugin-module-resolver so I have that and will look further into configuration options.

You brought up a burning question of mine:

Does Meteor run its own build process unless using serverEntry ( which I believe I am, per my last issue #215 ) such as when building for production? Is there a way for me to be sure Vite is also doing the production build?

@JorgenVatle
Copy link
Owner

JorgenVatle commented Nov 2, 2024

When using the serverEntry option, Vite will just bundle all your server assets into a single file which is then passed onto Meteor for the final build stage. Normally, Meteor will scan your entire project for files to include in the final server and client bundle. But with the serverEntry Meteor only has to load a single file which is already built by Vite.

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.

@JorgenVatle
Copy link
Owner

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.

@digitalextremist
Copy link
Author

digitalextremist commented Nov 2, 2024

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 meteor-vite as well as Meteor itself. And on my next build for meteor-base I will watch the log very closely.

Will check back once I get this solved and mention the solution. It seems like people specifically mention chalk and it might be a roundabout way of drawing attention to this ecosystem if there is package.json#imports note in the README.md mentioning that "as an example" knowing the vast majority of people get pulled into the issue by that, or Svelte I believe.

Making a lot more sense! I value these early difficulties to be able to understand the innards much better. Thanks again!

@digitalextremist
Copy link
Author

digitalextremist commented Nov 3, 2024

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 agentEntry and clientEntry

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 Vite bundle everything like that... just wow. For now, I dream and anticipate rolling up my sleeves to add support for that without harming the standard/default behavior, so it can become normal even if not widely used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants