Now that es5-shim has no impact on modern browsers (thanks to selectively
server-side rendering a <script> tag for older browsers), there's very
little reason not to use it.
If you really don't want to use it, you can always remove meteor-base and
install your preferred set of base packages.
Just as we were able to remove the SockJS polyfill library entirely from
the client JS bundle for modern browsers (#9353), we can do the same with
the `es5-shim` package.
The removes 28KB from the size of the minified JS bundle (before gzip).
It is no longer necessary for other packages to register weak dependencies
on `es5-shim`, because `es5-shim` will be reliably loaded in the `<head>`
if installed, which guarantees it will be evaluated before any bundled JS
in packages or the application.
In addition to loading `es5-shim` and `es5-sham` using `<script>` tags on
the client, we no longer evaluate either script on the server, since Node
8 has solid support for everything that previously needed shimming.
The original PR from @stubailo started the conversion to native
ECMAScript `class`es with 970f1fa7dd.
I might be projecting, but had there been time to finish that PR, I believe a
subsequent commit would have expunged the no-longer-necessary `self=this`
assignments, however I think that effort was lost in the hand-off.
In a previous commit, I changed
doc = _.extend({}, doc);
to avoid using underscore, thus:
doc = { ...doc };
While this may seem harmless, it broke a few Mongo.Collection tests
because _.extend copies *all* properties, both own and inherited, whereas
object ...spread only copies own properties.
However, the correct way to fix this problem is *not* to revert to the old
behavior, since flattening the inherited properties of a document was
never actually what we wanted. The old behavior was subtly broken, too.
Instead, we need to create a new object with the same prototoype as the
provided document, then shallow-copy the own properties. Any properties or
methods inherited from the original prototype will then be available on
the new object, even though they didn't get copied over.
I've intentionally left some trivial formatting changes in this commit to
remind myself which broken tests were fixed by this change.
Supersedes #9316, in which @stubailo demonstrated that SockJS can be
straightforwardly eliminated if native WebSocket support is assumed.
Native WebSocket support is close to universal now (94% of all clients
according to https://caniuse.com/#feat=websockets), which means we can
remove ~30KB of legacy code from the client bundle that we send to most
web browsers.
To achieve this flexibility, the sockjs-0.3.4.js script is injected as a
standalone <script> tag in the <head> of the document, but only if the
user agent string of the HTTP request fails to convince the sockjs-shim
package that the browser has native WebSocket support. When Meteor is
running in production, a minified version of that script is used instead.
Not only is this loading strategy a bit faster for older browsers, because
the SockJS script begins loading earlier, and is independent from the
normal JS bundle, it also removes the cost of loading SockJS completely
for more recent browsers.
Though it's tempting to keep hacking the SockJS script to make it smaller,
we should avoid spending too much time on that, since it only benefits a
small portion of users whose devices are likely to have poor performance
for lots of other reasons. In other words, I think we should keep
[Amdahl's Law](https://en.wikipedia.org/wiki/Amdahl%27s_law) in mind.
The contribution guidelines have a broken link to the documentation section. This fix uses the standard convention for the other links in this section.
It turns out we do not polyfill Object.entries, because that would require
requiring 'core-js/es7/object' in ecmascript-runtime-client/runtime.js.
Something to consider, but not strictly necessary right now.
https://github.com/meteor/meteor/pull/9338#discussion_r150306273
