This CL switches out the in-tree versions of en-US.json/en-XL.json
in favor of the versions generated at build time. They are identical.
The implementation is straight-forward. On the minification step, we
exclude the in-tree en-US.json/en-XL.json and instead add the
outputs of the "collect_strings" action (aka the generated en-US.json/
en-XL.json).
R=kimanh@chromium.org
Bug: 1185727
Change-Id: I923fba50033305a7df6bedccf65c657ecc8e5235
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4043247
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
This CL disables formatting within the `generated` directory, which is
all code that is programatically generated. Previously we disabled
eslint for `protocol.ts`, but now we are being consistent and disabling
it (and clang) for all files.
I also re-generated the files in the generated folder, so we avoid any
confusion if/when the generated scripts get re-run and suddenly the
format drastically changes.
DISABLE_THIRD_PARTY_CHECK=changing generated files + config
Bug: none
Change-Id: I714ada8bf7d85020e3be71b35c9db98840bf3ef2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3755163
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
This CL introduces support for writing inputs to wasm tests in wat
format. This will allow removing dependencies on opaque binary resources
that can't be regenerated without changing hardcoded offsets in all
tests. Referencing binary and/or source file offsets will now be
possible through special comments left in the wat source.
Bug: 1328729
Change-Id: I6369c86ca57860fd9803b894797f63c36c65d554
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3666419
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Use fast bundler if typecheck is skipped, assuming builders/developers
want to get result faster in such build config.
This will also remove the necessity of having devtools_fast_bundle
config from chromium CQ/CI's build.
This is step 6 of http://go/devtools-fast-bundle
Bug: 1278663
Cq-Include-Trybots: luci.devtools-frontend.try:devtools_frontend_linux_blink_light_rel_fastbuild,devtools_frontend_linux_dbg_fastbuild
Change-Id: I516b0af30c8c76c9382dfa09763d4efb8d1bdae7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3429380
Reviewed-by: Tim Van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Auto-Submit: Takuto Ikuta <tikuta@chromium.org>
Proposal: http://go/devtools-fast-bundle
This CL introduces build flag switching bundler from rollup.js to
esbuild by
* adding esbuild to npm without downloading binary packages
* making devtools_plugin for rollup.js re-usable to esbuild
On 24C/48T Z840 Linux machine, this shows following performance
difference by using
```
devtools_skip_typecheck = true
is_debug = false
```
as base build config.
esbuild (devtools_fast_bundle = true)
$ time ninja -C out/Default/
...
real 0m21.174s
user 2m47.513s
sys 0m38.549s
rollup.js (devtools_fast_bundle = false)
$ time ninja -C out/Default/
...
real 1m28.286s
user 30m19.220s
sys 5m36.392s
So esbuild is 3.2x faster and use only 9.6% of machine resouce
(user + sys) compared to rollup.js.
refs:
* https://esbuild.github.io/plugins/#on-resolve
* https://rollupjs.org/guide/en/#resolveid
Bug: 1278663
Cq-Include-Trybots: luci.devtools-frontend.try:devtools_frontend_linux_blink_light_rel_fastbuild,devtools_frontend_linux_dbg_fastbuild
Change-Id: If6b2e774f48091b0fe9c959e7ed1ed9bc2b0847c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3401984
Reviewed-by: Tim Van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
This adds an additional_readme_paths.json file that specifies all
directories of third_party packages that we include in the DevTools
bundle. The file is used as part of Chromiums about:credits machinery to
list all licenses of all third_party software (accessible via
chrome://credits).
It also updates the names of the packages to use the full name, which is
used as header of the license.
To ensure that this file remains up-to-date, we also include a GN action
that verifies all third_party directories listed in our GRD are included
in the .json file.
Lastly, add the missing license for Puppeteer.
R=yangguo@chromium.org
Bug: 1282407
Change-Id: Ia3142ab5bbc79804c56bc754934b9aaf1d186d7f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3386943
Commit-Queue: Tim Van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
To ensure that build timestamps don't unnecessarily cause full rebuilds,
make sure that we only write the generated contents to a file (if it
exists already) if it would be the same. This ensures that the file
timestamps remain the same, which will lead GN to conclude that the
build action is a noop (which it is).
On a new year, the file contents would actually be different, so it
would cause a proper rebuild. However, in all months between when the
timestamp changes, it won't cause is unnecessarily to rebuild all these
files, even though the year hasn't changed (but the timestamp it was
based on did).
R=jacktfranklin@chromium.org
Bug: 1283883
Change-Id: I2bdc3a79de710236c1501b21fa505692336cfa82
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3377942
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>
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>
Jack Franklin