Right now I have all of my client-side code in the public/ folder, running as plain JS. This is nice because I don’t have to worry about Meteor’s build system getting in the way. The code I write, is the code I get on the client, plain and simple, using native browser ES Modules.
However, every time I update code in the public/ folder, the server has to do a lengthy restart to copy over the update public/ folder so it can be served from the build inside .meteor/local.
It’d be great if updating the public folder did not require a full server restart. The file could simply be copied to the destination folder. Node Express or any Node.js static file server will simply serve new files that are placed into the served folder any time, dynamically, without a restart, so I believe we don’t need the Meteor app to be restarted on every change of public/ files.
Side thought: we already have the forums here, so it seems redundant to have feature requests on GitHub Discussions. A “feature request” category could easily be added here. Discourse has excellent plugins for thread voting too, so that threads can be sorted by most votes.
I mean that’s one way to try to solve the problem but I was thinking that since you purposefully put your files inside of /public to escape the build system why not place them inside some other folder and then use .meteorignore? There’re multiple ways to skin the cat but I’m not the one to judge.
(btw the current Meteor docs are missing any mention of .meteorignore)
An idea is maybe I can make my own “public” folder outside of public/. I should be able to use the Meteor.connectHandlers to add the static serve logic. But the problem with this is then I will need to make a Meteor build plugin to ensure that these files go into the app build. That would be quite a bit of work.
That seems like an anti pattern to Meteor as public is meant to be static. Could you not use a directory outside public, private, client, server and imports?
It needs to reload the server, as the files in /public are registered in WebAppInternals.staticFilesByArch. (Our app relies on it for CDN-related logic.)
I think there’s gotta be a way to update meteor core, for dev mode, to have the public/ folder simply symlinked where it needs to be to avoid server refreshes. Putting the public/ folder in the build outputs only matters for deploying.
All other frameworks I’ve tried serve public/ from a the original source without refresh, so this is just a current but unnecessary limitation of Meteor.
Did any of them provide a static object with the list of files in this directory? It’s simply impossible without a restart. This could be a function instead (listing files on demand), but that’d be a breaking change (it could be played off with a getter and a hook, but it seems too niche in my opinion).
I will handle this as part of the remaining documentation work for Meteor 3.4. .meteorignore has also been expanded in Meteor 3.4 to accept an environment variable (METEOR_IGNORE) to extend and customize the ignore list per command.
Exactly. I even had to make sure that when generating Rspack assets into the public folder, like dynamic imports, CSS, or other assets, they still go through Meteor’s asset management, so they get the same config as other Meteor static assets.
From my experience, the Meteor bundler has always reacted to the public folder to serve specific handling on reach them, and to make them available as artifacts for web and native architectures. It must watch it and handle its assets, and this is not something we can change easily without breaks.
To make Meteor 3.4 and Rspack integration as efficient as possible, I had to add a dynamic way to handle .meteorignore entries. That is why I added the METEOR_IGNORE env. I originally added it in a previous Meteor version, but in 3.4 I noticed it was not working as expected, so I fixed it and documented it.
Check the next PR. It was a good opportunity in 3.4 to document both .meteorignore and METEOR_IGNORE, following recent discussions on the forums.
We will try to document everything that is missing. The goal is not only to deliver features and modernizations, but also to document and maintain them properly (recently revisited all tutorials to adapt rspack specifics). If anyone feels something is missing, please report it, resurface it, or even contribute directly to the docs, so we can improve the framework together.
Interesting, I never used that feature. Never even needed that in any other app Meteor or not. I can’t find it in docs or anything meaningful in search engines. An AI was able to summarize it though, presumably from Meteor source code in its training.
An idea is, the server only needs to restart if files were added or removed. If the files only changed content, then the list is constant, and restart could be avoided for that case.
Another idea is, the server could update the list in dev mode instead of restarting, and for dev mode there could be something like Meteor.devRestart() to force restart if someone needs it (I’m betting most likely they don’t).
I wonder