This only affects newly created applications for now, but developers can
update to the latest meteor-node-stubs by running
meteor npm install meteor-node-stubs@latest
https://github.com/meteor/node-stubs/issues/15
IE10 does not support setting the __proto__ property of objects as an
alternative to Object.setPrototypeOf. Because Babel generates code that
uses the @babel/runtime/helpers/inheritsLoose helper, and that helper
relies on setting __proto__, subclassing fails in Babel-generated code in
IE10 (and earlier), which causes a white screen of death in newly created
Meteor apps.
This commit checks whether setting __proto__ works, and (if not) overrides
the inheritsLoose helper with an implementation that does not rely on
setting __proto__. This logic applies only in legacy browsers, thanks to
api.addFiles("legacy.js", "legacy").
Although this shim isn't perfect (for example, there is no way to set up
true inheritance of static properties), it will allow inheritance to work
in browsers that would otherwise be completely broken.
Since IE10 represents only 0.1% of the world market, we should not
overinvest in keeping it working, but this seemed like a good opportunity
to take advantage of legacy bundling, without adding any new code to the
modern bundle.
All Meteor packages implicitly depend on the meteor package, and the
meteor-base package implies the meteor package for most Meteor apps, but
the new minimal skeleton does not use meteor-base, so minimal Meteor apps
were not directly depending on the meteor package.
The only reason this mattered was that the meteor package registers a
default compiler plugin for CSS files, and compiler plugins only apply if
an app or package directly depends on them (or depends on a package that
implies them, such as meteor-base).
In other words, this change reenables support for raw CSS files for
minimal apps.
The only new functionality is the res.setHeader("Vary", "User-Agent")
call; the rest of the changes in this commit are just reformatting.
@CaptainN I think this should be enough information for well-behaved
browsers and CDNs to do the right thing, though I agree it's worth
documenting.
This still leaves web.cordova as the only architecture whose URLs get
prefixed (with /__cordova/), but the implementation better reflects the
special status of web.browser and web.browser.legacy as architectures that
the webapp and dynamic-import packages understand how to disambiguate
using the isModern test from the modern-browsers package.
Now that webapp can differentiate between modern and legacy browsers when
serving static files, without relying on URL prefixes, in principle we
shouldn't have to use prefixes for any URLs except Cordova ones.
Since legacy assets are no longer disambiguated from modern assets with a
/__browser.legacy/ URL prefix (#9776), we need a principled way to handle
collisions in the staticFiles registry.
