While doing some tests for meteor 3, I got annoyed that I needed to pass this command:
meteor run --exclude-archs web.browser.legacy web.cordova
In my proposal, I would create an issue(can be a good first issue IMO), with the required changes being, now, for adding those arches you would need to add:
--include-archs web.browser.legacy web.cordova
What do you guys think about it? Should we also change this since we are doing a breaking change in Meteor 3?
I think plain modern web apps are the most common, and I often want to write only code to be as close to hand-written as possible, then adjust my hand-written code only if as needed for a baseline set of browsers that I choose.
I go further and bypass Meteor’s build for the frontend by placing all my frontend code, in the form of ES Modules, inside of the public/ folder, so that what runs in the browser is exactly what I wrote, without Meteor’s custom build and module system causing any problem).
If anyone is curious, here’s the main.html that I use, which you can see has a script type=importmap for frontend dependencies (that I install locally in public/node_modules/):
The importmap links to meteor-packages.js which simply exports things from Package.* to make them available via the browser’s native import syntax:
Whenever I need a new Meteor package, I list it in meteor-packages.js, add the entry to the importmap, and am ready to import it into any file.
Then we see main.html loads the entry point:
We can see then that the code in the entry point is familiar, it imports libraries and meteor packages, continues as usual (noting that the import statements are not compiled, they run natively in the browser):
(I type check it all with TypeScript, hence the @ts-check comment).
