This CL re-writes `cmdevtools.css` to migrate all the colors over to
CSS variables, and defines those colors in dark mode also. To generate
this CSS I wrote a very hacky script that parsed the original CSS,
found all the colors, and then generated the variable names and
values. It used the original legacy color patching code to generate
the dark mode values.
Given `cmdevtools.css` now contains all dark mode overrides, this CL
removes the darkmode stylesheet for `cmdevtools.css`. Given that it's
the only dark mode CSS sheet, this CL also removes all the
infrastructure for generating and checking these sheets are up to
date.
The motivation for doing this work is that maintaining the darkmode
CSS stylesheets means we have to keep the legacy patching around in
order to (re)generate the stylesheets. Doing this one off script to
move all the overrides into the original file means we don't need to
keep the legacy patching around.
Bug: chromium:1152736
Change-Id: I0cf07d54370716299819478356b42728e0e3aadb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2982137
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
imported exist in the file system.
Initally, we wanted to create a `.d.ts` file for each CSS file to
ensure that the file being imported actually exists. However, when
ninja is building `tsc` uses the generated `tsconfig` file in `gen`.
In the `tsconfig.json` `files` list it will see the original TS file
that's in the source tree. When it goes to see the TS file and sees
the `import styles from 'foo.css.js'`. However, that file does not
exist in the files list of the entrypoint or the source tree, so TS
never finds it.
Instead we went with the approach of adding a `declare module` to type
all `.css.js` files and then use a lint rule to ensure that if you
import `foo.css.js` that there is a `foo.css` file in the tree.
Bug: 1106746
Change-Id: I8a65734bf4a9b359f8210b0011f14800c5d9426b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2953260
Commit-Queue: Kriti Sapra <kritisapra@google.com>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Currently, we optimize our SVGs out-of-sync and have a Python
script and PRESUBMIT check to make sure that the SVGs are correctly
optimized. This means that the SVGs are duplicated in the Images
folder and requires developers to install `svgo` on their command
line, which could be using differing versions.
Instead, we can optimize the SVG images (which is computationally
cheap) during build time using the rollup-plugin-import-meta-assets
and svgo packages. The rollup plugin traverses the required SVG
image files and puts them and rewrites them to the Images/ folder
(rather than in src/), while also allowing us to optimize them
along the way.
DISABLE_THIRD_PARTY_CHECK=Removing script from package.json
R=jacktfranklin@chromium.org
Bug: 1216402
Change-Id: Ieb6932b9a81753be5ecbccd00a5d84bd0efa23f8
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2939994
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This change replaces the 'spec' report with a 'mocha' report in karma
when the '--expanded-reporting' flag is set. If it is not set and the
tests fail, a hint is added to the console to enable the flag to get a
more verbose output of why the tests are failing.
Bug:None
Change-Id: Ia41615362332459a4d89aef0440cea0ec266157b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2912098
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Jan Scheffler <janscheffler@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>
This is a weird test case but if you've got Stylelint in your editor and
you're working on changing files, I've found that after typing "var("
(and my editor adding the closing ")"), the theme_colors rule tries to
run against this and fails as it expects the var() to contain a variable.
So if we do detect var(), we just do nothing and wait for the user to
actually fill it in.
Bug: chromium:1152736
Change-Id: Id78fa4f7b05a1107e609bd7b0cde5c0f4bbbc8e7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2896898
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Some files currently rely on the Protocol to be available on the
global scope. However, the Protocol definitions are defined in
a .d.ts file, which isn't available on runtime. Therefore,
attempting to import Protocol with non-type imports would retain
the imports in the `.js` files and break on runtime.
Since the only usages of the Protocol on runtime are the enums,
we can make them const, such that they get inlined as intended.
Then, `import * as` will work again, as the enums are inlined and
the import is removed from the `.js` file.
DISABLE_THIRD_PARTY_CHECK=Protocol update
R=jacktfranklin@chromium.org
Bug: 1208357
Change-Id: I749e57c9f51596866b61cab686c59f00bc8a8eb4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2897277
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>
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>
Jack Franklin