I'm not entirely sure this will work, but the alternative is having to
bump the patch version of every core package, so I'd like to see if this
simplification works first.
I've decided to stick with Meteor.isModern for now, since it's false for
both web.browser.legacy and web.cordova bundles, which would make logic
involving a hypothetical Meteor.platform property more complicated than
simply using Meteor.isModern. I'm open to revisiting this later.
https://github.com/meteor/babel-preset-meteor/blob/master/modern.jshttps://github.com/meteor/babel/blob/dfcce32868/options.js#L81
With the minimum versions from babel-preset-meteor/modern-versions.js, the
difference between "modern" and "legacy" browsers boils down to supporting
native async functions.
I'm eager to stop compiling generator functions with Regenerator, and none
of the transforms that compile async functions to native generator
functions seem much better than the Regenerator experience (source maps
are still wonky within the async function, so it's obvious you're not
working with native code).
Native async functions are supported by 73% of desktop and mobile browsers
worldwide (81% in the US), and that percentage is only going to keep
increasing. I see no reason not to embrace this future now.
This led to a regression in coffeescript-test-helper because the truthy
extraFeatures.runtime property allowed require("@babel/runtime/...") to
appear in a compiled CoffeeScript file, though require was not defined.
If @GeoffreyBooth agrees, we could have the coffeescript package
api.imply("modules"), which would make require would work, but I seem to
remember we had some reasons for not doing that previously.
In my research, I found the data used by @babel/preset-env to be more
conservative than necessary, so I have not followed their minimum version
constraints exactly.
For example, every feature of the ECMAScript `Map` API is clearly
supported in Firefox 45+, according to MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#Browser_compatibility
However, @babel/preset-env requires `core-js/modules/es6.map` in any
version of Firefox earlier than 53:
e270fbe7f0/packages/babel-preset-env/data/built-ins.json (L117)
Since I can't find any evidence that @babel/preset-env knows better than
other sources (I think they might just be using a compatibility table that
doesn't go back far enough), I have tentatively trusted MDN in picking
these versions.
If any bugs are ever reported due to this choice of versions and
polyfills, we have two options to fix them:
* Tighten the minimum version constraints so that the affected browsers
are considered legacy instead of modern.
* Include the missing `core-js` polyfills for all modern browsers.
Just as the URLs of static JS resources depend on request.browser, so too
must dynamic modules be loaded from the correct build directory based on
the user agent string of the __meteor__/dynamic-import/fetch HTTP request.
To save size in modern browsers, JavaScript bundles built for the
web.browser architecture no longer statically include the SockJS library.
That's safe as long as native WebSockets actually work, but what if
there's a problem with the network that necessitates falling back to
long-polling or some other SockJS strategy?
In those cases, we can load SockJS using a dynamic import(), which is a
little slower than including it in the bundle, but that's OK because the
module will be permanently cached in IndexedDB in production, and falling
back to SockJS should be rare in modern browsers anyway.
Note that this trick would not be possible if the implementation of
dynamic import() still required a socket connection! (#9384)
This traces back to my commit a9fde48ca8.
The problem went unnoticed because the only symptom was that duplicate
files were not properly reported.
The "compiler plugins - addAsset" self-test checks for the "Duplicate
source file" error, and was passing until recently, but began failing
after I fixed a bug in the forAllMatchingArchs function that allowed
duplicate callbacks for the same architecture.
May help prevent the problem that occurred in this Circle CI test run,
since lolex was the package with hash sha1-LycSsbwYDendzF06epbvPAuxYq0=:
https://circleci.com/gh/meteor/meteor/12641
We'll need to set up BrowserStack or headless Chrome tests to exercise
modern JS bundles. It is still very valuable to run tests with
web.browser.legacy in PhantomJS, because most day-to-day development
browsers qualify as "modern," and we don't want "legacy" browsers to
become a blindspot.
Now that both sockjs-shim and es5-shim are using the web.browser.legacy
system instead of injecting <script> tags with the server-render package,
these shared utilities are no longer used anywhere.
Since Cordova renders boilerplate HTML at build time, and doesn't use the
server-render system through the webapp package, it's important that we
include es5-shim (and sham) statically for Cordova clients.
This logic will go away once we have the web.browser.legacy system to
control differential bundling (#9439), but for now it's necessary for any
Cordova clients that still don't have full ECMAScript 5 support.
Previously, .cache filenames were simply a hash of the absolute path of
the inputFile, which allowed for cache collisions (on disk) between the
same file compiled for different architectures (web.browser, os.*, ...).
Now, the .cache filenames are generated based on whatever information the
compiler plugin deems uniquely identifying about the input file: whatever
is returned from getCacheKey, plus the absolute path of the file.
This code was recently removed in PR #9445, with this commit:
d644705aa8
Rather than removing deprecated code entirely from the codebase, I think
it's sufficient to keep it in packages/deprecated, and print a deprecation
notice whenever the package is used. This way it's clear that developers
should migrate to other similar packages, but we can still release
important patches for those who haven't been able to migrate yet.
cc @hwillson @abernix
