This CL updates `generate_css_files` script and `watch` script to enable us to get CSS file changes instantly applied for non-legacy CSS files.
Drive by:
* Added an initial build step before starting to watch changes(1)
* Improved logs to include the time of the change.
* Updated `watch` listener to only get activated on `change` events.
(1) was something I was always missing starting this script.
You can try the behavior by:
* Running `npm run watch` and starting the watch mode.
* Opening the DevTools.
* Updating a non-legacy CSS file and expect to see the CSS change instantly on the opened DevTools.
Bug: none for now
Change-Id: I2aa3ed1b36584d1ef011119d5092d12271fb3017
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4922476
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Ergün Erdoğmuş <ergunsh@chromium.org>
The code generator embeds the last n entries of its own filename into
the generated InspectorBackendCommands. It used to be n=4, which
happens to create a different filename depending on whether the
script is run from a chromium or a standalone devtools-frontend
checkout. So set n=3.
DISABLE_THIRD_PARTY_CHECK=Updating code genrator
Bug: none
Change-Id: I09fad6d43377c8558709cbe41dba106f9c813caf
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4852085
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Philip Pfaffe <pfaffe@chromium.org>
We need access to the typeRef for array parameters. At the moment string type was not supported.
Moreover, the registerType only contains types relating to objects. This CL adds support as well for types directly relating to arrays.
DISABLE_THIRD_PARTY_CHECK=needed to build
Bug: 1462270
Change-Id: I0375228a9315e35819c93e7deeb149121765f52b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4665825
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Hadrien Jaubert <hadrienjaubert@google.com>
The protocol Monitor needs to know the type of array parameters. To do this, the CL will add type reference to registerType inside the InspectorBackendCommands.js file. It is then possible to know what type of parameters array parameters accept.
DISABLE_THIRD_PARTY_CHECK=needed to build
Bug: 1462096
Change-Id: I623ef4fef1f49f7618f2a874490a515ce22ce1cd
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4660370
Commit-Queue: Hadrien Jaubert <hadrienjaubert@google.com>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This CL adds the ability to have access to a map enabling the user to have access to all the keys of object parameters. To do that, this CL modifies code_generator_frontend.py to generate a new command called RegisterType.
DISABLE_THIRD_PARTY_CHECK=make build work
Bug: 1458788
Change-Id: I28bf0baf3841cf3120d103e40925698d3c8114b2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4650362
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Hadrien Jaubert <hadrienjaubert@google.com>
DevTools has two ways to build release builds:
* tsc + rollup + terser
* and esbuild.
THe GN arg "devtools_skip_typecheck" decides which of the two
toolchains is used, as the esbuild one is much faster and enough
for the average Chromium developer.
Until now, the "devtools_release_sourcemaps" only works with the
rollup toolchain. This CL implements sourcemaps also for esbuild.
This means that "devtools_release_sourcemaps" now works
independently of "devtools_skip_typecheck".
This is convinient for dogfooding our own source map support in
DevTools: Now we can test against both rollup and esbuild with
DevTools-on-DevTools.
R=jacktfranklin@chromium.org
Bug: 1430396
Change-Id: I54849764a26f3fb539535eccdde7a79f9fd00d5f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4654605
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
We need to retain the metadata for deprecations past the point where
they are no longer dispatched on stable. This provides a way to turn
codegen off at the same time as we note the milestone when the metadata
can be safely removed.
Bug: 1451772
Change-Id: I9fb9ef4b8fbecaa2fb8d14ad65016102387bf722
DISABLE_THIRD_PARTY_CHECK=Testing codegen changes
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4594037
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This CL adds a new GN flag "devtools_release_sourcemaps" (off by
default.. When set, we'll instruct rollup to generate source maps for
the bundles. This means that every entrypoint, e.g. 'common.js', now
has a corresponding source map ('common.js.map').
We also use 'rollup-plugin-sourcemap'. It is responsible for consuming
the source maps generated by the TypeScript compiler and merge them
with the source map produced by rollup. This allows us to still
debug on the level of TypeScript files even for minified release
builds.
R=jacktfranklin@chromium.org
Fixed: 1430396
Change-Id: I3a0f94dc722f19d066725aef3544652c6a19c95a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4402891
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
We now roll a "deprecation.json5" file from blink into DevTools that
serves as the canonical source for deprecations: It contains the
english message + note for translators as well as additional
metadata such as milestone and chrome feature number.
To use the .json5 in a somewhat type-safe way, we generate
TypeScript that is type-checked against the DeprecationIssueType
from CDP.
Note that we also generate a standard UIStrings structure that
we'll import in "DeprecationIssue.ts". An alternative would be to
collect to strings directly from the .json5 but that would
complicate "npm run collect-strings" as we'd have to teach those
scripts how to parse the .json5.
DISABLE_THIRD_PARTY_CHECK=Add newly generated file
R=alexrudenko@chromium.org
Bug: 1411444
Change-Id: Ifcfd4291ebfc3a70c100ba4a5fbefc485d4a5493
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4227691
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
We had to disable CSSNano because it was causing broken fonts in release
builds (exact reason TBC). This CL installs the `cssnano-preset-lite`
package which applies only the following optimisations:
1. remove whitespace
2. remove empty rules (e.g. `div{}`).
3. remove comments
This should be far less risky and unlikely to cause unexpected
breakages.
DISABLE_THIRD_PARTY_CHECK=installed & used cssnano-preset-lite in the
same CL.
Bug: 1399763
Change-Id: I7fdd8b70b02a2c1a5e1c71a87c7ba145114e6e4b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4111923
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
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>
Sandor Major