I confirmed that devtools_skip_typecheck works in chromium CQ in
https://crrev.com/c/3435231/6
This improves build time of chrome like belows
* 279.3s -> 223.7s in debug build
* 327.8s -> 170.7s in release build
on my 24C/48T Z840 Linux machine when goma backend cache is warmed.
Caveat is slight increase of execution time in tests if that run
devtools code path.
https://crbug.com/1278663#c90
Bug: 1278663
Cq-Include-Trybots: luci.devtools-frontend.try:devtools_frontend_linux_blink_light_rel_fastbuild,devtools_frontend_linux_dbg_fastbuild
Change-Id: Ie9e5b4788a36fd46b259376baf35beeccecab70c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3439325
Reviewed-by: Tim Van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
We had to revert resetting timestamps for all typescript
targets to combat non-determinism in the production build. However,
the Node targets that we have do not suffer from the same fate:
they don't need to integrate with Rollup and don't expose a separate
entrypoint that you need to use types for.
Therefore, opt-in all Node targets to efficient rebuilding. This
should speed up the rebuilding of all test targets under test/e2e.
R=jacktfranklin@chromium.org
Bug: none
Change-Id: If50e7fd25a483825d85c4e235499059f5c1472d9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3158383
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
When working on upgrading `@types/node` I discovered that our
Karma unit tests were accidentally including our Node types,
even though these tests don't run in a Node environment.
As it turns out, we were including the `node_modules/@types`
folder in our compilations when `opts.test_only` is set. Since
our unittests are marked as `test_only`, they would then pull
in *all* `@types` packages.
To combat that problem, we can use yet another TypeScript config
option that allows us to specify which exact packages TypeScript
is allowed to pull in. We list all packages that we currently rely
on in the relevant environments, so that we are no longer
accidentally including `@types/node` in our Karma unit tests.
R=jacktfranklin@chromium.org
Bug: none
Change-Id: I896297e3af7a72068b68e2424da2c89b3935573e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3158228
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
The previous attempt was wrong, as it wasn't correctly rebuilding
dependents if a breaking TypeScript API change was made. The root
cause for that is the split of `devtools_entrypoint` and
`devtools_module`, which we need for bundling. Unfortunately, we
also can't introduce granular GN targets for only `.d.ts` files,
since TypeScript generates all outputs in 1 go. Therefore, it is not
possible to split that up into multiple scripts, which is required
if we want to introduce targets with outputs for only `.d.ts`.
Instead, we should still reset timestamps for `devtools_module`,
but then we always rebuild `devtools_entrypoint`. By doing that,
a breaking API change in a `devtools_module` would trigger its
corresponding `devtools_entrypoint` to change, which will ensure
that all its dependents also change. However, the next layer of
`devtools_module` will then detect that it doesn't change, hence
introducing the performance improvement.
So while we are still doing a bit too much work in theory, in practice
this change already removes a whole bunch of unnecessary work. I
think that is a step in the right direction and this should result
in deterministic builds as well.
DISABLE_THIRD_PARTY_CHECK=Update TypeScript infrastructure
R=jacktfranklin@chromium.orgCC=marijnh@gmail.com
Bug: 1237438
Change-Id: Ib8ea10ee8df263f0dddf0918bc1732fd696f1105
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3107130
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This reverts commit 5c9fbe66ff.
Reason for revert: Breaks compilation of API breakages of existing
methods.
Original change's description:
> Fix recompilation issues with timestamps for generated sourcemaps
>
> Recently, we have been observing increased GN recompilation times.
> It's unclear why they started happening (we are currently thinking
> it was related to an update of the TypeScript compiler), but we did
> discover a bug in our timestamp resetting behavior.
>
> When inspecting the build output, I discovered that the timestamps
> for the `.js.map` files would always be increased, even if the content
> was unchanged. The `.js` and `.d.ts` maps would see their timestamps
> properly reset.
>
> As it turns out, the replacement extension that we used to reset
> all files was `.map` rather than `.js.map`. That's because the source
> map files that would be generated would end in `.js.map` and since
> the original file ends with `.ts`, we have to do the full replacement.
>
> I have confirmed that making a single change in a random file that
> does not affect the public API will properly work.
>
> R=jacktfranklin@chromium.org
>
> Fixed: 1237438
> Change-Id: Iaec168c45632845e3da140e7cdb0a621a3d1702f
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3081731
> Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
> Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
> Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Bug: 1237438
Change-Id: Ia0394ef3b22a06deacb912f21a901aacb1141d7e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3093156
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Recently, we have been observing increased GN recompilation times.
It's unclear why they started happening (we are currently thinking
it was related to an update of the TypeScript compiler), but we did
discover a bug in our timestamp resetting behavior.
When inspecting the build output, I discovered that the timestamps
for the `.js.map` files would always be increased, even if the content
was unchanged. The `.js` and `.d.ts` maps would see their timestamps
properly reset.
As it turns out, the replacement extension that we used to reset
all files was `.map` rather than `.js.map`. That's because the source
map files that would be generated would end in `.js.map` and since
the original file ends with `.ts`, we have to do the full replacement.
I have confirmed that making a single change in a random file that
does not affect the public API will properly work.
R=jacktfranklin@chromium.org
Fixed: 1237438
Change-Id: Iaec168c45632845e3da140e7cdb0a621a3d1702f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3081731
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Incremental compilations can break if engineers clean their out
directory with `ninja -t clean` and then attempt to recompile.
This has historically also led to spurious build failures when
output directories are manually (incorrectly) cleaned.
Instead, we should remove these `.tsbuildinfo` files. These files
are a side-effect of enabling `incremental: true`, which is
required to enable incremental recompilation based on previous
build output. However, we don't actually need to use these files
for up-to-dateness checks, as GN already "runs the world".
Therefore, after any compilation (even unsuccesful ones), we
should manually remove these files.
Confirmed to fix when building and cleaning:
```
autoninja -C out/Default inspector_overlay:build_inspector_overlay
ninja -C out/Default -t clean front_end/core/common:bundle
autoninja -C out/Default inspector_overlay:build_inspector_overlay
```
R=alexrudenko@chromium.org
Fixed: 1225476
Change-Id: I1f236187d3a80fd7f3eb6281cc77b92bb645410f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3006575
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Some files that don't import codemirror itself do refer to types
as declared by CodeMirror, which therefore need to implicitly
side-effect import the types. The reason being that these files
are used in both the standalone and full version of CodeMirror
(depending on whether they run in a worker context or not).
Therefore, they can't import `third_party/codemirror/codemirror.ts`,
as that would only contain the full version.
DISABLE_THIRD_PARTY_CHECK=Tsc update
R=szuend@chromium.org
Bug: 1209844
Change-Id: I8719a15b40e9d9f085b24c05af4372ad84812d1f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2897979
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Not every single ts_library invocation has (and should have) access
to the ESTree types. Therefore, re-export these types via Acorn,
which is the only user of these types.
This also improves the build performance, as we are no longer
rebuilding all of DevTools when these types change.
DISABLE_THIRD_PARTY_CHECK=Tsc cleanup
R=szuend@chromium.org
Bug: 1209844
Change-Id: Ib182ba4f7877d26eea844ac75180542ce2bac44a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2900444
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Currently, all Protocol type definitions live on the global scope.
Additionally, the protocol files are included in all ts_library
targets. However, we don't want the protocol definitions to be
available in, for example, reusable UI components.
Therefore, we should move to a system where all files that want
to refer to the protocol types should import them instead.
However, doing so in 1 large CL will be problematic, which is
why it should be both globally available and importable as an
interim step.
To do so, we augment the existing protocol definitions to export
them as namespace and regular export. Then, we introduce a separate
file that imports the protocol types and augments the global scope
with the definitions. Now, protocol is both importable and remains
available on the global scope.
The reason that we need a separate file is that TypeScript disallows
you to augment the global scope in a file that also exports types.
Therefore, the global scope augmentation happens in protocol-globals.d.ts,
which will be removed once all Protocol type usages are imported.
To verify that this approach works, ProtocolClient imports the
required types, while SDK only imports it in AccessibilityModel.
All other files in SDK still refer to the global type.
In follow-up CLs, all pre-existing usages of Protocol will use
the import style.
DISABLE_THIRD_PARTY_CHECK=Updating protocol type format
R=szuend@chromium.org,jacktfranklin@chromium.org
Bug: 1208357
Change-Id: I1d75949b9cd3e37989c6cddf79ac849f5664a1e3
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2891756
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Prior to the resources/inspector removal, we were having efficient
recompilations with GN. However, after the resources/inspector removal,
GN was excessively recompiling targets that don't require recompilation.
After an extensive investigation, we discovered that the root cause is
a discrepancy between what `tsc` determines to be a "new" file and when
Ninja does. Essentially, `tsc` uses content-based hashing to determine
freshness, whereas Ninja looks at file timestamps.
Therefore, if `tsc` generated the same output, `tsc` thought that nothing
had changed. However, `tsc` always writes the output, meaning that the
filestamps changed and then Ninja picked that up concluding "I need to
rerun dependent actions, as the output changed".
Therefore, we need to mimic what Ninja expects based on the file contents
of what `tsc` generates. To do so, we augment `ts_library` to obtain
any previously generated file content and store the corresponding file
timestamps. After `tsc` did its job, we compare the newly generated
content to the previous content. If we determine that they are equivalent,
we force-reset the timestamps of the files. This allows Ninja to conclude
that nothing has changed.
We do a similar fix for the generated `tsconfig.json`, but there we can
directly compare the newly generated configuration with the old configuration
and only perform the write if necessary.
The reason this improves incremental compilation is the fact that we split
up the implementation of a module with the entrypoint of a module. If you
make an implementation change in a module, the `ts_library` will have changed,
which means that it directs dependents will run. Since the only direct
dependent of a `devtools_module` is the corresponding `devtools_entrypoint`,
the `devtools_entrypoint` action will run. However, since the
`devtools_entrypoint` action will generate an equivalent public API, all
users of the entrypoint will not rebuild. Therefore, implementation-only
changes will now only cause recompilations of the module, but none of their
dependents.
R=aerotwist@chromium.orgCC=dpranke@google.com
Also-By: dpranke@google.com
Bug: 1139220
Change-Id: I9cafe33f92ce70fb638884b850c873987687d5a4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2837838
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
In release mode, the devtools_entrypoint prebundle step was missing
the deps. We ran into this issue when we were moving the emulation
panel into panels/emulation, which required some updates to the
toolbox.ts entrypoint (crrev.com/c/2782540).
The missing deps then required the rootdir logic to be changed,
such that deps are correctly resolved relative to the gen-directory,
not the source directory.
This CL might improve build performance in release builds, since
we are now properly using incremental references for our
entrypoints and saving a bit of compilation time.
DISABLE_THIRD_PARTY_CHECK=TypeScript fix
R=aerotwist@chromium.org
Bug: 1187573
Change-Id: I4662ac90ba50116cb668dfe3164fe725b74f9a37
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2782554
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
All relevant build output files are now put into gen/front_end.
To make sure that we don't run into duplicate JS entrypoint
files, we have to turn of the emit of these targets in
front_end/BUILD.gn, such that build_release_applications can
put its output there. Since build_release_applications takes
the files from the front_end source directory, not the gen
directory, this causes no issues.
After this change, it is possible to use --custom-devtools-frontend
with gen/front_end rather than resources/inspector.
DISABLE_THIRD_PARTY_CHECK=Update TypeScript noemit
R=aerotwist@chromium.org
Bug: 1174013
Change-Id: Iad331ff0a28871a0ec297483fa03fbb485d05fb4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2672031
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This is a reland of 159d86d3fb
The reland fixes the setting of "use_rbe" on the ts_library template
iff RBE is enabled for devtools directly. This prevents an
"unused variable" error when building with "use_rbe=true" and
"devtools_use_rbe=false".
Original change's description:
> Support RBE for building TypeScript int DevTools
>
> This CL implements initial support for executing TSC in the cloud by:
> 1) Introducing a new GN arg "devtools_use_rbe". This is experimental
> and will be folded into the Chromium "use_rbe" flag once RBE
> building has stabalized.
> 2) Pass the configured Chromium rewrapper along to ts_library.py.
> 3) Add a new function "runTscRemote" that calculates inputs required
> and invokes rewrapper
>
> Support is currently very limited:
> - Only works with a full Chromium checkout (NOT standalone DevTools)
> - Only works on leaf modules (modules without DEPS)
>
> Modules that can't be currently built in the Cloud are built locally
> as per usual.
>
> DISABLE_THIRD_PARTY_CHECK=Change typescript.gni
>
> R=tvanderlippe@chromium.org
>
> Bug: chromium:1139220
> Change-Id: Id7a1e6c113466414f6daaa661456d8debfe6696d
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2652508
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
DISABLE_THIRD_PARTY_CHECK=Change typescript.gni
Bug: chromium:1139220
Change-Id: I536fb580c3814a82525344ab5ebd5fb853568387
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2659015
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
This reverts commit 159d86d3fb.
Reason for revert:
This has broken a few re-client builders in Chromium:
* https://ci.chromium.org/p/chromium/builders/ci/Linux%20Builder%20%28reclient%29?limit=200
* https://ci.chromium.org/p/chromium/builders/ci/Linux%20Builder%20%28reclient%29
```
$ gn gen out/rbe-demo --args='use_rbe=true is_debug=false'
ERROR at //third_party/devtools-frontend/src/scripts/build/ninja/devtools_entrypoint.gni:132:19: Assignment had no effect.
use_rbe = false
^----
You set the variable "use_rbe" here and it was unused before it went
out of scope.
See //third_party/devtools-frontend/src/front_end/common/BUILD.gn:47:1: whence it was called.
```
Original change's description:
> Support RBE for building TypeScript int DevTools
>
> This CL implements initial support for executing TSC in the cloud by:
> 1) Introducing a new GN arg "devtools_use_rbe". This is experimental
> and will be folded into the Chromium "use_rbe" flag once RBE
> building has stabalized.
> 2) Pass the configured Chromium rewrapper along to ts_library.py.
> 3) Add a new function "runTscRemote" that calculates inputs required
> and invokes rewrapper
>
> Support is currently very limited:
> - Only works with a full Chromium checkout (NOT standalone DevTools)
> - Only works on leaf modules (modules without DEPS)
>
> Modules that can't be currently built in the Cloud are built locally
> as per usual.
>
> DISABLE_THIRD_PARTY_CHECK=Change typescript.gni
>
> R=tvanderlippe@chromium.org
>
> Bug: chromium:1139220
> Change-Id: Id7a1e6c113466414f6daaa661456d8debfe6696d
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2652508
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
TBR=szuend@chromium.org,tvanderlippe@chromium.org
Change-Id: Ie82249ab143f86bc61d706759b7b72c43ba4c53f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1139220
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2658258
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@google.com>
Reviewed-by: Takuto Ikuta <tikuta@chromium.org>
Commit-Queue: Ye Kuang <yekuang@google.com>
This CL implements initial support for executing TSC in the cloud by:
1) Introducing a new GN arg "devtools_use_rbe". This is experimental
and will be folded into the Chromium "use_rbe" flag once RBE
building has stabalized.
2) Pass the configured Chromium rewrapper along to ts_library.py.
3) Add a new function "runTscRemote" that calculates inputs required
and invokes rewrapper
Support is currently very limited:
- Only works with a full Chromium checkout (NOT standalone DevTools)
- Only works on leaf modules (modules without DEPS)
Modules that can't be currently built in the Cloud are built locally
as per usual.
DISABLE_THIRD_PARTY_CHECK=Change typescript.gni
R=tvanderlippe@chromium.org
Bug: chromium:1139220
Change-Id: Id7a1e6c113466414f6daaa661456d8debfe6696d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2652508
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Our node tests run in the Node environment. As such, they already
include more type information, like Node, Mocha and Chai types.
However, it turns out that we did not update the moduleResolution
flag to enforce Node. Therefore, it was using the classic TypeScript
module resolution algorithm.
This wasn't a problem per se, as the classic algorithm will resolve
files in the same way as Node does. However, there is a slight
side-effect in that one of our `@types` we load references a type
that is specified in `@types/node`. The classic algorithm
erroneously traverses up the file tree to look for the filename,
in this case `stream`. If an engineer working on Chromium would
have a file called `stream.ts` in a parent directory of
`chromium/src`, then the classic algorithm would incorrectly resolve
to that file.
Instead, we should force the Node resolution algorithm, which
will not resolve to the `stream.ts` file, but will instead use
the types as defined in `@types/node`.
R=aerotwist@chromium.org
Fixed: 1135451
Bug: 1011811
Change-Id: I8ada319c923114f049f14fe38dcd8df82a9f2da8
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2461774
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This file was using `Headers` as iterable. This class is iterable,
but TypeScript didn't like it. As it turns out, there are multiple
definitions of the `dom` and `webworker` APIs. To get the iterable
versions, we have to add them explicitly. Therefore, also update
our TypeScript configuration to add the iterable variants.
DISABLE_THIRD_PARTY_CHECK=TypeScript fix
R=szuend@chromium.org
Bug: 1011811
Change-Id: Iae32bbf25d55346081dc2e0ab4f4093b531f91a1
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2421705
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Required changes:
- Add CodeMirror types as globals
- Add support for `is_web_worker` in `ts_library` and
`devtools_module`, as the FormatterWorker is a worker. This
also moves the `lib` specification out of `tsconfig.base.json`,
as we now need to dynamically generate it
- Fix (seemingly unrelated) issues with untyped events in other
files. I don't understand why TSC suddenly started to complain
about these.
DISABLE_THIRD_PARTY_CHECK=TypeScript fixes
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1098730
Change-Id: I7d33c22983f2fe5e793c20fa5d56411d996ec999
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2294985
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This introduces the first TypeScript-authored file that also makes
use of TypeScript features. To do so, we have to perform several steps:
1. Move the `formatter_worker` typescript files into a new template called
`devtools_module`. This template takes care of running TypeScript and
copying the files it generates to `resources/inspector`. (The latter can
be removed when we are in a position to do so)
2. Move the files out of `all_devtools_modules` into (yet another) GN variable.
We should clean this up by using the `grd_file_group`, which is possible
with an integration with `devtools_module`. However, for simplicity's sake
I decided to fix that in a follow-up. The integration of `devtools_module`
with the GRD action script would then finally allow us to remove the duplication
of all of these file strings in multiple places.
3. To make sure that the buildgraph remains intact, we have to perform
the copy-step after the typescript-step. However, this means we need to use
a different name than `target_name` for the typescript compilation. We run
into issues there, as the project references assume that the names are the
full folder names (e.g. `../formatter_worker`). If we would then use a different
name for the `ts_library` action, then we generate a `tsconfig.json` with
the wrong name. To counteract that, introduce a (temporary)
`typescript_config_name` where we can explicitly set the name of the `tsconfig.json`
that we generate. This is not ideal and I am still thinking of a better
alternative, but haven't figured out a solution yet.
DISABLE_THIRD_PARTY_CHECK=Typescript fixes
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1098730
Change-Id: I1457067845cdedbc7d4ce6a80c12d7943b67087c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2282809
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Port formatter_worker to use devtools_entrypoint, which is the abstraction
around `rollup`. It handles the creation of the rollup bundle, but leaves
it alone if you are building with `is_debug=true`. This way, we can keep
development use the existing workflow where individual files are fetched,
while in release mode we bundle the entrypoint into 1 big file.
In the future, anything we consider an entrypoint must use this method.
This would include third_party packages like lit-html and CodeMirror.
A follow-up CL will move the lit-html entrypoint back into
third_party/lit-html, as we no longer require it to be a direct subfolder
of `front_end/` (that was fixed in
https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2270168)
DISABLE_THIRD_PARTY_CHECK=TypeScript fixes
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1098730
Change-Id: I5d2e67cc9c71291e8b67bbc29354e75239aae9a9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2267001
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This is a reland of d274209d78
Original change's description:
> Reland "Reland "Add rollup_entrypoint to rollup entrypoints in front_end""
>
> This reverts commit 786fb877e8.
>
> Reason for revert: https://chromium-review.googlesource.com/c/chromium/src/+/2258469
> no longer includes DevTools frontend in the Android build, fixing the issue
> where Android was including DevTools frontend twice.
>
> Original change's description:
> > Revert "Reland "Add rollup_entrypoint to rollup entrypoints in front_end""
> >
> > This reverts commit dbb8f31857.
> >
> > Reason for revert: suspected cause of build breakage downstream:
> > https://ci.chromium.org/p/chromium/builders/ci/Android%20arm64%20Builder%20%28dbg%29/42557?blamelist=1#blamelist-tab
> >
> > Original change's description:
> > > Reland "Add rollup_entrypoint to rollup entrypoints in front_end"
> > >
> > > This is a reland of 9f16ccc6a1
> > >
> > > Original change's description:
> > > > Add rollup_entrypoint to rollup entrypoints in front_end
> > > >
> > > > To support lit-html in a release build, we have to run rollup
> > > > separately. Since lit-html source code is targeted to TypeScript,
> > > > the entrypoint front_end/lit-html/lit-html.ts is a TypeScript-authored
> > > > file.
> > > >
> > > > This means that we can't use `build_release_applications.py` to rollup
> > > > this file (this is by design). Instead, we introduce a new
> > > > `rollup_entrypoint` Ninja target that calls Rollup. We don't have to
> > > > write a special Python file, as we can reuse `node.py` for this, which
> > > > is essentially a pipe-through with a pinned version of Node.
> > > >
> > > > While the rollup build works, for debug builds we are still missing
> > > > the `front_end/third_party/lit-html` files. We will address that
> > > > in a follow-up CL, once we introduce the first usage of lit-html
> > > > in the codebase.
> > > >
> > > > We are going to need to make more changes to Rollup later (most notably
> > > > the external files check), but since we aren't using this codepath
> > > > in `build_release_applications.py`, I will fix that in a separate CL.
> > > >
> > > > To reduce duplication in the Ninja build system, I also extract
> > > > a vars.gni file that has the relevant variables. These are currently
> > > > used in the rollup.gni and typescript.gni.
> > > >
> > > > Lastly, I had to fix node.py to make sure it wouldn't always print
> > > > the stdout. In Ninja, we should only print to stdout if there is
> > > > an error.
> > > >
> > > > DISABLE_THIRD_PARTY_CHECK=Ninja fixes
> > > > R=jacktfranklin@chromium.org,aerotwist@chromium.org
> > > >
> > > > Bug: 1011811, 1061037
> > > > Change-Id: Ib22ff9c1d78e61c922101444f27c4f0d4ccf9bd6
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2238232
> > > > Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
> > > > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > > > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> > >
> > > DISABLE_THIRD_PARTY_CHECK=Ninja fixes
> > >
> > > Bug: 1011811, 1061037, 1096473
> > > Change-Id: I5695c445f8456b6447c836dead89bdd4cf98b0fa
> > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2247646
> > > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > > Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
> > > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> >
> > TBR=aerotwist@chromium.org,tvanderlippe@chromium.org,jacktfranklin@chromium.org
> >
> > Change-Id: Ia6fd6111181500ad44c7757321d141f320b1edf5
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Bug: 1011811, 1061037, 1096473
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2257954
> > Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
> > Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
>
> DISABLE_THIRD_PARTY_CHECK=Ninja fixes
>
> Bug: 1011811, 1061037, 1096473
> Change-Id: I9b0fb13bfff83ea91599e69cb024b8ddf51b3c79
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2260353
> Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
DISABLE_THIRD_PARTY_CHECK=Ninja fixes
Bug: 1011811, 1061037, 1096473
Change-Id: I908a5d923e0a874af372793a74a92e9873d5c07e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2273186
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This reverts commit 786fb877e8.
Reason for revert: https://chromium-review.googlesource.com/c/chromium/src/+/2258469
no longer includes DevTools frontend in the Android build, fixing the issue
where Android was including DevTools frontend twice.
Original change's description:
> Revert "Reland "Add rollup_entrypoint to rollup entrypoints in front_end""
>
> This reverts commit dbb8f31857.
>
> Reason for revert: suspected cause of build breakage downstream:
> https://ci.chromium.org/p/chromium/builders/ci/Android%20arm64%20Builder%20%28dbg%29/42557?blamelist=1#blamelist-tab
>
> Original change's description:
> > Reland "Add rollup_entrypoint to rollup entrypoints in front_end"
> >
> > This is a reland of 9f16ccc6a1
> >
> > Original change's description:
> > > Add rollup_entrypoint to rollup entrypoints in front_end
> > >
> > > To support lit-html in a release build, we have to run rollup
> > > separately. Since lit-html source code is targeted to TypeScript,
> > > the entrypoint front_end/lit-html/lit-html.ts is a TypeScript-authored
> > > file.
> > >
> > > This means that we can't use `build_release_applications.py` to rollup
> > > this file (this is by design). Instead, we introduce a new
> > > `rollup_entrypoint` Ninja target that calls Rollup. We don't have to
> > > write a special Python file, as we can reuse `node.py` for this, which
> > > is essentially a pipe-through with a pinned version of Node.
> > >
> > > While the rollup build works, for debug builds we are still missing
> > > the `front_end/third_party/lit-html` files. We will address that
> > > in a follow-up CL, once we introduce the first usage of lit-html
> > > in the codebase.
> > >
> > > We are going to need to make more changes to Rollup later (most notably
> > > the external files check), but since we aren't using this codepath
> > > in `build_release_applications.py`, I will fix that in a separate CL.
> > >
> > > To reduce duplication in the Ninja build system, I also extract
> > > a vars.gni file that has the relevant variables. These are currently
> > > used in the rollup.gni and typescript.gni.
> > >
> > > Lastly, I had to fix node.py to make sure it wouldn't always print
> > > the stdout. In Ninja, we should only print to stdout if there is
> > > an error.
> > >
> > > DISABLE_THIRD_PARTY_CHECK=Ninja fixes
> > > R=jacktfranklin@chromium.org,aerotwist@chromium.org
> > >
> > > Bug: 1011811, 1061037
> > > Change-Id: Ib22ff9c1d78e61c922101444f27c4f0d4ccf9bd6
> > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2238232
> > > Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
> > > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> >
> > DISABLE_THIRD_PARTY_CHECK=Ninja fixes
> >
> > Bug: 1011811, 1061037, 1096473
> > Change-Id: I5695c445f8456b6447c836dead89bdd4cf98b0fa
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2247646
> > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
> > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
>
> TBR=aerotwist@chromium.org,tvanderlippe@chromium.org,jacktfranklin@chromium.org
>
> Change-Id: Ia6fd6111181500ad44c7757321d141f320b1edf5
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: 1011811, 1061037, 1096473
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2257954
> Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
> Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
DISABLE_THIRD_PARTY_CHECK=Ninja fixes
Bug: 1011811, 1061037, 1096473
Change-Id: I9b0fb13bfff83ea91599e69cb024b8ddf51b3c79
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2260353
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
This reverts commit dbb8f31857.
Reason for revert: suspected cause of build breakage downstream:
https://ci.chromium.org/p/chromium/builders/ci/Android%20arm64%20Builder%20%28dbg%29/42557?blamelist=1#blamelist-tab
Original change's description:
> Reland "Add rollup_entrypoint to rollup entrypoints in front_end"
>
> This is a reland of 9f16ccc6a1
>
> Original change's description:
> > Add rollup_entrypoint to rollup entrypoints in front_end
> >
> > To support lit-html in a release build, we have to run rollup
> > separately. Since lit-html source code is targeted to TypeScript,
> > the entrypoint front_end/lit-html/lit-html.ts is a TypeScript-authored
> > file.
> >
> > This means that we can't use `build_release_applications.py` to rollup
> > this file (this is by design). Instead, we introduce a new
> > `rollup_entrypoint` Ninja target that calls Rollup. We don't have to
> > write a special Python file, as we can reuse `node.py` for this, which
> > is essentially a pipe-through with a pinned version of Node.
> >
> > While the rollup build works, for debug builds we are still missing
> > the `front_end/third_party/lit-html` files. We will address that
> > in a follow-up CL, once we introduce the first usage of lit-html
> > in the codebase.
> >
> > We are going to need to make more changes to Rollup later (most notably
> > the external files check), but since we aren't using this codepath
> > in `build_release_applications.py`, I will fix that in a separate CL.
> >
> > To reduce duplication in the Ninja build system, I also extract
> > a vars.gni file that has the relevant variables. These are currently
> > used in the rollup.gni and typescript.gni.
> >
> > Lastly, I had to fix node.py to make sure it wouldn't always print
> > the stdout. In Ninja, we should only print to stdout if there is
> > an error.
> >
> > DISABLE_THIRD_PARTY_CHECK=Ninja fixes
> > R=jacktfranklin@chromium.org,aerotwist@chromium.org
> >
> > Bug: 1011811, 1061037
> > Change-Id: Ib22ff9c1d78e61c922101444f27c4f0d4ccf9bd6
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2238232
> > Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
> > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
>
> DISABLE_THIRD_PARTY_CHECK=Ninja fixes
>
> Bug: 1011811, 1061037, 1096473
> Change-Id: I5695c445f8456b6447c836dead89bdd4cf98b0fa
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2247646
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
> Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
TBR=aerotwist@chromium.org,tvanderlippe@chromium.org,jacktfranklin@chromium.org
Change-Id: Ia6fd6111181500ad44c7757321d141f320b1edf5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 1011811, 1061037, 1096473
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2257954
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
This is a reland of 9f16ccc6a1
Original change's description:
> Add rollup_entrypoint to rollup entrypoints in front_end
>
> To support lit-html in a release build, we have to run rollup
> separately. Since lit-html source code is targeted to TypeScript,
> the entrypoint front_end/lit-html/lit-html.ts is a TypeScript-authored
> file.
>
> This means that we can't use `build_release_applications.py` to rollup
> this file (this is by design). Instead, we introduce a new
> `rollup_entrypoint` Ninja target that calls Rollup. We don't have to
> write a special Python file, as we can reuse `node.py` for this, which
> is essentially a pipe-through with a pinned version of Node.
>
> While the rollup build works, for debug builds we are still missing
> the `front_end/third_party/lit-html` files. We will address that
> in a follow-up CL, once we introduce the first usage of lit-html
> in the codebase.
>
> We are going to need to make more changes to Rollup later (most notably
> the external files check), but since we aren't using this codepath
> in `build_release_applications.py`, I will fix that in a separate CL.
>
> To reduce duplication in the Ninja build system, I also extract
> a vars.gni file that has the relevant variables. These are currently
> used in the rollup.gni and typescript.gni.
>
> Lastly, I had to fix node.py to make sure it wouldn't always print
> the stdout. In Ninja, we should only print to stdout if there is
> an error.
>
> DISABLE_THIRD_PARTY_CHECK=Ninja fixes
> R=jacktfranklin@chromium.org,aerotwist@chromium.org
>
> Bug: 1011811, 1061037
> Change-Id: Ib22ff9c1d78e61c922101444f27c4f0d4ccf9bd6
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2238232
> Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
DISABLE_THIRD_PARTY_CHECK=Ninja fixes
Bug: 1011811, 1061037, 1096473
Change-Id: I5695c445f8456b6447c836dead89bdd4cf98b0fa
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2247646
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This reverts commit 9f16ccc6a1.
Reason for revert: Fails in Chromium roll: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8877691983703106912/+/steps/compile__with_patch_/0/stdout
Original change's description:
> Add rollup_entrypoint to rollup entrypoints in front_end
>
> To support lit-html in a release build, we have to run rollup
> separately. Since lit-html source code is targeted to TypeScript,
> the entrypoint front_end/lit-html/lit-html.ts is a TypeScript-authored
> file.
>
> This means that we can't use `build_release_applications.py` to rollup
> this file (this is by design). Instead, we introduce a new
> `rollup_entrypoint` Ninja target that calls Rollup. We don't have to
> write a special Python file, as we can reuse `node.py` for this, which
> is essentially a pipe-through with a pinned version of Node.
>
> While the rollup build works, for debug builds we are still missing
> the `front_end/third_party/lit-html` files. We will address that
> in a follow-up CL, once we introduce the first usage of lit-html
> in the codebase.
>
> We are going to need to make more changes to Rollup later (most notably
> the external files check), but since we aren't using this codepath
> in `build_release_applications.py`, I will fix that in a separate CL.
>
> To reduce duplication in the Ninja build system, I also extract
> a vars.gni file that has the relevant variables. These are currently
> used in the rollup.gni and typescript.gni.
>
> Lastly, I had to fix node.py to make sure it wouldn't always print
> the stdout. In Ninja, we should only print to stdout if there is
> an error.
>
> DISABLE_THIRD_PARTY_CHECK=Ninja fixes
> R=jacktfranklin@chromium.org,aerotwist@chromium.org
>
> Bug: 1011811, 1061037
> Change-Id: Ib22ff9c1d78e61c922101444f27c4f0d4ccf9bd6
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2238232
> Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
TBR=aerotwist@chromium.org,tvanderlippe@chromium.org,jacktfranklin@chromium.org
Change-Id: Ida2a1e30d601e87f64a7c35bbc527c700d9cbe70
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 1011811, 1061037
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2243175
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
To support lit-html in a release build, we have to run rollup
separately. Since lit-html source code is targeted to TypeScript,
the entrypoint front_end/lit-html/lit-html.ts is a TypeScript-authored
file.
This means that we can't use `build_release_applications.py` to rollup
this file (this is by design). Instead, we introduce a new
`rollup_entrypoint` Ninja target that calls Rollup. We don't have to
write a special Python file, as we can reuse `node.py` for this, which
is essentially a pipe-through with a pinned version of Node.
While the rollup build works, for debug builds we are still missing
the `front_end/third_party/lit-html` files. We will address that
in a follow-up CL, once we introduce the first usage of lit-html
in the codebase.
We are going to need to make more changes to Rollup later (most notably
the external files check), but since we aren't using this codepath
in `build_release_applications.py`, I will fix that in a separate CL.
To reduce duplication in the Ninja build system, I also extract
a vars.gni file that has the relevant variables. These are currently
used in the rollup.gni and typescript.gni.
Lastly, I had to fix node.py to make sure it wouldn't always print
the stdout. In Ninja, we should only print to stdout if there is
an error.
DISABLE_THIRD_PARTY_CHECK=Ninja fixes
R=jacktfranklin@chromium.org,aerotwist@chromium.org
Bug: 1011811, 1061037
Change-Id: Ib22ff9c1d78e61c922101444f27c4f0d4ccf9bd6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2238232
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Takuto Ikuta