To remove the module.json file in perf_ui, we need to migrate the
resources to the new `generate_css` template. However, perf_ui is a bit
special, in that it doesn't properly use the widget structure. As such,
it sometimes injects CSS in places where there is no clear shadowRoot
available. Therefore, it is not possible to migrate to CSSStyleSheet in
combination with adoptedStylesheets.
As a workaround (to unblock the module.json removal), we augment
`generate_css` to add legacy file generation. All remaining resources in
DevTools will migrate to these `.css.legacy.js` files. That's because
these resources either are special (perf_ui) or are used in the
`device_mode_emulation_frame` which can't use `CSSStyleSheet` itself.
The files export an object, rather than a plain string. That's because
we need to be able to distinguish what string is referencing a CSS file
path and which strings contain the actual CSS styles. By using an
object, we can remain using the `typeof` check for string in the legacy
CSS infrastructure and otherwise destructure the object.
After this, we can remove perf_ui from the module.json structure and
properly bundle+minify the CSS resources.
R=jacktfranklin@chromium.org
Bug: 1190991, 1127902
Change-Id: I7523333e8025ae5fe5ed74b99b4e45907ff9ad97
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3275787
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>
These scripts check if a file exists and whether its content is
different from a source file before copying it. However the file look up
done with fs.existsSync() could be case-insensitive depending on the
underlying file system.
This CL implements the a case-sensitive file look up to compare against
the exact path name of the file being copied.
Bug: none
Change-Id: I0dc175c2292b3caea541a585562e8e25db637340
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3256666
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Andres Olivares <andoli@chromium.org>
This patch ensures we collapse spaces between DOM nodes
into a single space rather than removing the space entirely.
This prevents issues with missing spaces in UI text, and
generally makes the HTML minification step more safe.
Bug: chromium:1264791
Change-Id: Ib8dfaa58e973ee8682a1f43226db9f9483d9606b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3252958
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Mathias Bynens <mathias@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 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>
Tim van der Lippe