Specifically, this desupports:
android 4.4.3-4.4.4
baidu 7.12
ie 11
kaios 2.5
op_mini all
although we’ve already been blocking IE 11 since 3.0 (#14662).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This enables core-js modules for proposals marked as finished between
core-js 3.0 and 3.6. It’s recommended upstream, although it has no
current effect for us.
The PROVISION_VERSION bump is skipped because there is no actual
dependency change.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This has the consequence of turning on loose mode for
@babel/proposal-class-properties, which generates slightly smaller
code.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
ES and TypeScript modules are strict by default and don’t need this
directive. ESLint will remind us to add it to new CommonJS files and
remove it from ES and TypeScript modules.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Due to try-catch deoptimization, Babel strict mode for…of loops run
about 5× slower in Firefox than Babel loose mode for…of, native
for…of, or forEach (which are all about the same speed). Chrome
doesn’t seem to care.
For some reason we need to explicitly add the core-js Symbol polyfill
near the beginning of the common bundle. Otherwise it gets loaded at
the wrong time and the Casper tests fail.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
This has different resolution semantics that we need to take advantage
of: .babelrc only applied to files within its own package.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
Anders Kaseorg
Anders Kaseorg