This CL adds a new script to compress files using brotli. The new script
maintains a cache of compressed files so if the file was previously
compressed and has not been changed, it is not compressed again.
The compression happens only in release builds. Also, this CL
includes JSON into the compression list saving ~0.7MB in binary size.
Bug: chromium:1211337
Change-Id: I8ed8189d762f5532a261d748cbc2eb8a4be9a25e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2905507
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Currently, we have the dependencies on the generated locales
scattered into `front_end/` and the `test/unittests/`. However,
i18n should typically be the only folder that should know about
the locales. The reason we split these off, is that we don't want
to rebuild all of DevTools whenever somebody changes a localization
string.
That said, with the recent updates to the build system, it is
now possible to add them to `public_deps`, to ensure we don't
need to rebuild all of DevTools.
R=szuend@chromium.org
Bug: none
Change-Id: I9892362032c80862cc224682fe5dc73fde91af21
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2912720
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
By moving the configuration file to `scripts/build`, we are correctly
using the `moduleResolution = 'node'`. Then, we enable TypeScript with
`// @ts-check`, we get warnings in VS Code. There were some small fixes.
Mostly that it removed an unnnecessary closure and `buildStart` hook,
which we no longer require. Additionally, the `output` format now
conforms to what Rollup expects.
R=jacktfranklin@chromium.org
Bug: none
Change-Id: I55daf8e6f3e32f81afd9e0b13ffc7b49bddfedfc
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2910110
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@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>
In the Chromium backend engineers can use `DCHECK()` to ensure
certain invariants are held, but only execute these assertions
in a debug build. [1] Release builds do not ship with DCHECKS enabled.
In a similar fashion, introduce a build-time generated function
`DHCECK` that is only generated when `devtools_dcheck_always_on`
is set as GN arg. By default, `is_debug` builds enable
`devtools_dcheck_always_on`. However, in a release build, you can
explicitly set `devtools_dcheck_always_on` to `true` to achieve
the same effect.
When the GN arg is set, the build generates the `dcheck.js` file
with an implementation that checks the condition and fails if
it is not met. When the arg is not set, the function implementation
remains empty and becomes a noop.
To make sure that these functions calls are removed in a release
build (rather than being a noop), the terser configuration is
updated to treat these functions as pure. As such, terser will
remove any calls if the function implementation is empty. In a
release build that explicitly turns out the dchecks, terser
will not remove the function calls.
Lastly, to make sure that all code related to the dcheck is removed,
the condition needs to be a lambda. If we were to make it a raw
boolean, then `terser` would not be able to determine whether it
can remove the condition itself and would leave that behind. In other
words, the `DCHECK` call would still leave some artifacts behind,
namely the condition computation itself. By making it a lambda,
terser can deduce that the lambda creation has no side-effect and
remove the lambda if the `DHCECK` call is removed.
R=aerotwist@chromium.org
[1]: https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++.md#check_dcheck_and-notreached
Bug: none
Change-Id: Ic396f102141d9eb67c8690bd2a601b56061b9d8c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2894390
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This locks down the visibility of ui/legacy:bundle to the various
folders that already depend on it. For now, the visibility is
quite broad, as there is still plenty of code depending on the
legacy UI implementation.
Consequently, downstream projects (such as the Edge DevTools fork)
will break if they depend on this bundle. Therefore, add a GN arg
that allows the visibility to be extended. To use this GN arg,
downstream projects can change their `default_args` in the root
`.gn` file:
default_args = {
devtools_ui_legacy_visibility = [
"//front_end/forked/folder/*",
]
}
This means that they can broaden the visibility of UI. It is still
recommended to remove as many of the dependencies on UI as feasible,
but that will likely not finish any time soon.
R=jacktfranklin@chromium.org,aerotwist@chromium.org
Bug: 1202788
Change-Id: I868e88ee3b1c66dd7c79d30d07648a7d2828e8f2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2853551
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
GN metadata allows to specify and later query metadata from any
action in our build graph. Using GN metadata, we can specify
GRD files on an action and collect these files on the top level.
Then, we can compare the list of collected files to the expected
GRD files in `devtools_grd_files.gni` to ensure they match.
As a follow-up change, we can remove the intermediate lists we have
been specifying in `all_devtools_modules.gni` and
`devtools_module_entrypoints.gni`, which now become obsolete. That's
because both `devtools_module` and `devtools_entrypoint` now specify
the files in their respective metadata and essentially perform the
check that all relevant files are collected.
R=aerotwist@chromium.org
Also-By: alexrudenko@chromium.org
Bug: 1174013
Change-Id: I9dd2e6f7e010b5c25f83556511af12d5d1c2ec7c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2843322
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@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>
This also updates the Runtime and build_release_applications to use
the correct format for the various files. Most notably, it should
use the basename when concatening file names, since we don't want
to include the `panels/` part in these file names. As such, the
filenames become `panels/accessibility/accessibility_module.js`.
R=aerotwist@chromium.org
Bug: 1187573
Change-Id: I2d3d453ac0e5ea0d4358228531bfe31bde6e7655
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2757147
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This reverts commit 037c96df04.
Reason for revert: upstream revert: https://crrev.com/c/2713518
Original change's description:
> Stop copying to resources/inspector in devtools_{module,entrypoint}
>
> This simplifies the JavaScript generating tasks in the DevTools
> build system to stop copying to resources/inspector. The output
> to the gen-folder will remain as-is.
>
> After this change, it will no longer be possible to use
> resources/inspector as build output location when using
> --custom-devtools-frontend. Instead, the location should be
> updated to use gen/front_end instead. Engineers are encouraged
> to remove the resources/inspector build output folder to ensure
> stale build artifacts aren't accidentally used while working
> on DevTools locally.
>
> Note that there are still files in resources/inspector generated by
> other actions in the build system. We will clean these up in
> follow-up CLs.
>
> R=alexrudenko@chromium.org,jacktfranklin@chromium.org
>
> Bug: 1174013
> Change-Id: I750d04e58c5fa85054b8451c3582b58a3f7c77ba
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2678696
> Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
> Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Bug: 1174013
Change-Id: I9c4c561a59d808d3fdd1564475ec5ba21955d577
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2714545
Auto-Submit: Changhao Han <changhaohan@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This simplifies the JavaScript generating tasks in the DevTools
build system to stop copying to resources/inspector. The output
to the gen-folder will remain as-is.
After this change, it will no longer be possible to use
resources/inspector as build output location when using
--custom-devtools-frontend. Instead, the location should be
updated to use gen/front_end instead. Engineers are encouraged
to remove the resources/inspector build output folder to ensure
stale build artifacts aren't accidentally used while working
on DevTools locally.
Note that there are still files in resources/inspector generated by
other actions in the build system. We will clean these up in
follow-up CLs.
R=alexrudenko@chromium.org,jacktfranklin@chromium.org
Bug: 1174013
Change-Id: I750d04e58c5fa85054b8451c3582b58a3f7c77ba
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2678696
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Kriti Sapra