I commonly have to do this lately, otherwise I have to fiddle with Babel config too much, or build output bugs. It seems to be targeting very old browsers, and all the syntax is basically supported in all browser nowadays.
Plus, typically I also never need web.cordova because I’m building web apps.
Maybe the defaults should be changed so that meteor runs with --exclude-archs web.browser.legacy web.cordova by default, and let people opt in?
I think it’s a good suggestion! I thought the same a while ago.
Let’s see what other devs think. 
We can change the default behavior to skip building legacy and Cordova in development until the server receives a request for them. If I remember correctly, MDG had considered this and decided to wait to see if delayed builds would be good enough. The benefit of the current behavior is since every arch is built every time in development we know if there’s a problem building an arch immediately instead of when deploying.
Hmm. Yeah. Two issues:
npm start script I hard code the options for the meteor command, then I’m on my way.It seems like if #1 was kept up to date, then perhaps there’d be less issues with legacy build, and keeping all builds as default would just work.
I disabled those build because, when they broke (things break when they get old and tooling keeps moving forward), I didn’t want to spend any time on them knowing I didn’t need them so I disabled them.
Could you explain how legacy broke? Did it break building the app, or would the server sometimes serve the legacy client instead of the modern in development?
We still have code to support ES3, so even moving the minimum to ES5 would be an improvement. I’m not sure about moving the minimum to es6 at this point. Using native es6 classes would remove many problems. There are new issues like Errors attempting to run fresh svelte project + Android platform · Issue #12173 · meteor/meteor · GitHub where there are syntax errors even with the more widely supported es6 features, and some companies that use Meteor still support IE last I heard.
Typically issues with babel runtime being installed but the build complaining it isn’t installed. Since I didn’t need legacy build, disabling was easier the troubleshooting.
If you encounter that issue again and it isn’t too much trouble, I would love to see a reproduction. I’ve fixed some causes for that error the last couple of years, but there might be more.
Sure, I’ll do that if it happens again. I ran npm ls, and it showed me Babel runtime there and deduped in all packages as would be expected, so it was strange that it wasn’t being picked up for some reason.