I’ve noticed lately in Monti ( but I guess people using other Kadria variants see the same ) that a lot of modern browsers on one of our apps are using the web.browser.legacy architecture. Here’s a few examples of browsers I’ve seen get the legacy bundle.
Safari (WebKit) - 13.1.2 Mac OS - 10.15.4
Chrome - 85.0.4183.133 Chromium OS - 13310.93.0
Mobile Safari (WebKit) - 14.0 iOS - 14.0.1, mobile - Apple iPhone
But there are also examples of some getting the correct modern bundle. It seems a bit random?
In our other app much older versions of different browsers are getting the modern (web.browser) bundle as you’d expect.
Chrome - 85.0.4183.133 Chromium OS - 13310.93.0
Both apps are on Meteor 1.11 and whilst there are differences they use a pretty similar set of packages.
Has anyone had any experience with this? Any ideas for debugging it?
The modern-browsers package decides if the legacy or modern architecture should be used. When the server starts, packages or the app call setMinimumBrowserVersions to configure the minimum browser versions that support the modern architecture. There doesn’t seem to be an API to access the minimum versions, but you could start Meteor with meteor --inspect and create a breakpoint in the modern-browsers package to check what it is set to in each app.
I’ve noticed lately in Monti ( but I guess people using other Kadria variants see the same ) that a lot of modern browsers on one of our apps are using the web.browser.legacy architecture.
This feature is unique to Monti APM. I’m excited that it was useful for you.
I’m wondering if our Cordova (both iOS and Android) are using modern browser or legacy. We’re using the paid version of Monti. I just don’t have any idea where to look for it.
Cordova is a separate architecture, but it is considered legacy and mostly includes the same code and is compiled in the same way as the legacy web arch. How the modern and legacy architectures are designed is legacy is the default architecture since it should work almost anywhere, and the modern arch is considered an optional optimization for when Meteor knows the client supports it. With that design, the legacy arch worked better for cordova.
Monti APM shows the architecture for client errors, which I assume @marklynch was referring to. We’re working on a new feature to monitor the client, which will show how many users use each architecture, and which browsers are using the legacy arch.
@zodern , thanks for the detailed explanation. Not what I hoped but very interesting indeed.
We’re trying to debug Google Maps JS API on Cordova. Their latests release have implemented ES2020 natively and they stopped working on Cordova (both Android and iOS) even with recent webviews that should, from our understanding, support ES2020.
So we had the hypothetis it was because Cordova was using legacy
We have done one very interesting test in Cordova through Chrome Inspector (idea of @receptim), we ran our app using :
1-The standard localhost:12924 port (so using the bundle made for Cordova)
2-Through an external URL that connects to the Node server directly
We see clearly that both:
1-Can run ES2020 functions
2-Have exactly the same Array.from (it was a possible cause for our Google Maps problems)
However, their “Map” object is different and that messes up with Google Maps JS API.
Here, see the test:
let oda=new Map([[1,["msie"]],[2,["edge"]],[3,["chrome","crios"]],[5,["firefox","fxios"]],[4,["applewebkit"]],[6,["trident"]],[7,["mozilla"]]]);
for(const [d,e]of aoda.entries()){ console.log('d='+d +' e='+e)}
In Localhost:12490, it fails with the same error as Google Maps’s JS API
While on modern bundle, it works just fine:
Why is that object different?
How can we put it back like it is in a modern browser bundle ?
