Igor Minar a1001f2ea0 fix(core): disable tsickle pass when producing APF packages (#37221)
As of TypeScript 3.9, the tsc emit is not compatible with Closure
Compiler due to
https://github.com/microsoft/TypeScript/pull/32011.

There is some hope that this will be fixed by a solution like the one
proposed in
https://github.com/microsoft/TypeScript/issues/38374 but currently it's
unclear if / when that will
happen.

Since the Closure support has been somewhat already broken, and the
tsickle pass has been a source
of headaches for some time for Angular packages, we are removing it for
now while we rethink our
strategy to make Angular Closure compatible outside of Google.

This change has no effect on our Closure compatibility within Google
which work well because all the
code is compiled from sources and passed through tsickle.

This change only disables the tsickle pass but doesn't remove it.

A follow up PR should either remove all the traces of tscikle or
re-enable the fixed version.

BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments
to support Closure Compiler's advanced optimizations

The support for Closure compiler in Angular packages has been
experimental and broken for quite some
time.

As of TS3.9 Closure is unusable with the JavaScript emit. Please follow
https://github.com/microsoft/TypeScript/issues/38374 for more
information and updates.

If you used Closure compiler with Angular in the past, you will likely
be better off consuming
Angular packages built from sources directly rather than consuming the
version we publish on npm
which is primarily optimized for Webpack/Rollup + Terser build pipeline.

As a temporary workaround you might consider using your current build
pipeline with Closure flag
`--compilation_level=SIMPLE`. This flag will ensure that your build
pipeline produces buildable and
runnable artifacts, at the cost of increased payload size due to
advanced optimizations being disabled.

If you were affected by this change, please help us understand your
needs by leaving a comment on https://github.com/angular/angular/issues/37234.

PR Close #37221
2020-05-21 09:14:47 -07:00

105 lines
4.5 KiB
Python

load(":angular_integration_test.bzl", "angular_integration_test")
# Some integration ports must be managed manually to be unique and in other
# cases the tests are able to select a random free port.
#
# Where `ng e2e` is used we pass `ng e2e --port 0` which prompts the cli
# to select a random free port for the the e2e test. The protractor.conf is
# automatically updated to use this port.
#
# Karma automatically finds a free port so no effort is needed there.
#
# The manually configured ports are as follows:
#
# TEST PORT CONFIGURATION
# ==== ==== =============
# dynamic-compiler 4201 /e2e/browser.config.json: "port": 4201
# hello_world__closure 4202 /e2e/browser.config.json: "port": 4202
# hello_world__systemjs_umd 4203 /bs-config.e2e.json: "port": 4203
# i18n 4204 /e2e/browser.config.json: "port": 4204
# ng_elements 4205 /e2e/browser.config.json: "port": 4205
# platform-server 4206 /src/server.ts: app.listen(4206,...
# Map of integration tests to tags.
# A subset of these tests fail or are not meant to be run with ivy bundles. These are tagged
# "no-ivy-aot".
INTEGRATION_TESTS = {
"bazel": {
"tags": [
# Bazel-in-bazel tests are resource intensive and should not be over-parallized
# as they will compete for the resources of other parallel tests slowing
# everything down. Ask Bazel to allocate multiple CPUs for these tests with "cpu:n" tag.
"cpu:3",
"no-ivy-aot",
],
},
"bazel-schematics": {
"tags": [
# Bazel-in-bazel tests are resource intensive and should not be over-parallized
# as they will complete for the resources of other parallel tests slowing
# everything down. Ask Bazel to allocate multiple CPUs for these tests with "cpu:n" tag.
"cpu:3",
"no-ivy-aot",
],
},
"cli-hello-world": {"commands": "payload_size_tracking"},
"cli-hello-world-ivy-compat": {"commands": "payload_size_tracking"},
"cli-hello-world-ivy-i18n": {
"commands": "payload_size_tracking",
# TODO: (FW-2165) cli-hello-world-ivy-i18n fails on a bundle size check with Ivy bundles
"tags": ["fixme-ivy-aot"],
},
"cli-hello-world-ivy-minimal": {"commands": "payload_size_tracking"},
"cli-hello-world-lazy": {
"commands": "payload_size_tracking",
# TODO: (FW-2165) cli-hello-world-lazy fails on a bundle size check with Ivy bundles
"tags": ["fixme-ivy-aot"],
},
"cli-hello-world-lazy-rollup": {
"commands": "payload_size_tracking",
# TODO: cli-hello-world-lazy-rollup fails on a bundle size check because Ivy and VE sizes are different
"tags": ["no-ivy-aot"],
},
"dynamic-compiler": {"tags": ["no-ivy-aot"]},
"hello_world__closure": {
"commands": "payload_size_tracking",
"tags": ["no-ivy-aot"],
},
"hello_world__systemjs_umd": {
# Special case for `hello_world__systemjs_umd` test as we want to pin
# `systems` at version 0.20.2 and not link to the the root @npm//systemjs
# which is stuck at 0.18.10 and can't be updated to 0.20.2 without
# breaking the legacy saucelabs job.
"pinned_npm_packages": ["systemjs"],
},
"i18n": {"tags": ["no-ivy-aot"]},
"injectable-def": {"tags": ["no-ivy-aot"]},
"ivy-i18n": {"tags": ["no-ivy-aot"]},
"language_service_plugin": {},
"ng_elements": {"tags": ["no-ivy-aot"]},
"ng_elements_schematics": {"tags": ["no-ivy-aot"]},
"ng_update": {},
"ng_update_migrations": {"tags": ["no-ivy-aot"]},
"ngcc": {"tags": ["no-ivy-aot"]},
"platform-server": {"tags": ["no-ivy-aot"]},
"service-worker-schema": {},
"side-effects": {"tags": ["no-ivy-aot"]},
"terser": {},
"typings_test_ts39": {
# Special case for `typings_test_ts39` test as we want to pin
# `typescript` at version 3.9.x for that test and not link to the
# root @npm//typescript package.
"pinned_npm_packages": ["typescript"],
},
}
[
angular_integration_test(
name = test_folder,
commands = INTEGRATION_TESTS[test_folder].get("commands", "default"),
pinned_npm_packages = INTEGRATION_TESTS[test_folder].get("pinned_npm_packages", []),
tags = INTEGRATION_TESTS[test_folder].get("tags", []),
)
for test_folder in INTEGRATION_TESTS
]