An entry point file for an app makes total sense but for tests it would be a big deterioration to not just include all *.tests.* files. Would it be possible to keep that mode for tests only?
1 Like
In my MeteorāRspack app, I first compiled each *.test.js separately by finding them and adding each as a bundler entry. That added overhead and hurt performance. I switched to a single entry point that I maintain manually with āmeteor.testModuleā.
Iām open to adding an automatic āvirtualā entry point, limited to tests, as it only seems to require listing .tests.js files that are likely independent, and ensure watcher keeps active filling that entry point. This approach appears efficient to keep. Iāll consider it for the first beta if time allows, otherwise later.
Definitely, app entrypoints are needed, as you noted. With the app we canāt guarantee the proper load order. We could try to mimic what Meteor internals do, but thatās likely time consuming. I donāt have experience with it yet.
I also considered automatically adding entry points when a project lacks them, as @radekmie suggested here. I could automate it later, and it would help others replicate the process and migrate their apps to proper entry points.
1 Like
Yes I +1 the wanting the test files. note that there are two version .app-test and .test that are the difference between unit test files and functional test files.
It would be possible to do it manually, but its a nice piece of meteor architecture that would be annoying to lose
1 Like