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>
There are a handful of e2e tests which test regressions, and consequently
have a bug assiciation. This association was part of the test names in
the same way as we reference bugs for skipped tests. If such a test is
then skipped it needs to start with two crbug references. That's
confusing for the reader as well as a the skipped test lint check, for
which the regression bug references can lead to false negatives. This CL
introduces a new lint check that prevents bug references in non-skipped
tests with the same syntax as skipped tests.
Bug: none
Change-Id: Ibdf59091aba942f85424c1f12cc31160d9fe786a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2761357
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This CL lands the initial new run_test_suite.js that can take its
configuration from a config JSON file, or from flags.
This new script is only used to run `npm run auto-interactionstest`
and nothing more; I want to roll it out slowly and ensure that
everyone is aware of it before removing the old Python script. I will
create a doc with all the various steps, and required documentation,
as I've taken the chance to rename some options to make them clearer.
Bug: chromium:1186163
Change-Id: I5a199f82ac7ab0f323988acacaa7aae2d64e6349
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2763866
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
The Localization presubmit steps include checking Loc V1 and V2:
V1: Done with migration, safe to remove
V2:
- check unused string in UIStrings (Moved to ESLint)
- check migrated directory (Done with migration, safe to remove)
- check the shape of API calls (Done by typescript or ESLint)
Since all checks are obsolete or moved, this CL removes the presubmit step to unhook the scripts inside scripts/localization. I will follow up a CL to remove the actual scripts.
The CL that introduced this step https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1931279
Bug: 1136655
Change-Id: If203607588896693a6331de606c873458b74cd6e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2746919
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Christy Chen <chrche@microsoft.com>
The current test suite runner assumes the paths; you pass
--test-suite=interactions and it assumes that they live in
out/TARGET/gen/test/interactions. This CL removes that assumption by
asking people to pass --test-suite-path, which would be
out/gen/interactions.
We will remove the --test-suite flag, but for now we're keeping it
around so the bots can still run their tests. I will file a bug to ask
that the bots have their recipes updated.
Bug:1182255
Change-Id: I6d9e5d419231845047394c5f7cbd0c74ebad3a58
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2722448
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This CL turns on the use_theme_colors stylelint rule which enforces that
any colors use variables defined in our codebase.
There are many, many violations, unsurprisingly (about 1500), so for now
I have disabled every single violation. The goal of the dark mode
migration will be in part to remove all violations of this rule.
Additionally, new code going forwards should adhere to the rule and not
add the comment to disable the warning.
Bug: 1152736
Change-Id: I51372724ea51485daef3d4f75b7d3f60a7c8016f
No-Presubmit: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2671323
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This CL introduces "npm run check-external-links". The check parses
all string literals in first party JS/TS code for Urls. All the Urls
are then "pinged" by making a HEAD request to verify they still point
to an active resource. Example output:
$ time npm run check-external-links
> chrome-devtools-frontend@ check-external-links /usr/local/google/home/szuend/dev/devtools/devtools-frontend
> third_party/node/node.py --output scripts/check_external_links.js
Collecting JS/TS source files ... 1019 files found.
Collecting Urls from files ...248 unique Urls found.
Sending a HEAD request to each one ...
All Urls are accessible and point to existing resources.
npm run check-external-links 9.21s user 0.40s system 149% cpu 6.415 total
Please note that we can't make this check part of our PRESUBMIT, as
it makes external requests.
Also note that this check can't be implemented as an ESLint rule,
as ESLint rules are not allowed to have an async workload.
R=aerotwist@chromium.org, sigurds@chromium.org
Bug: chromium:1170310
Change-Id: I064161dd9038143d2e360c1716f8fb622dc119ee
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2659021
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
As part of the work to move more scripts to Node, not Python, over time,
picked this one as the starting point. I changed its API slightly to
allow more flags to be taken in, as we'll need that to do a stylelint
pass against TypeScript files, but I will do that in a subsequent CL.
I had to make quite a few changes to devtools_paths.js, but I think it's
now calculating paths correctly. It took a bit of messing to get the
equivalent of Python's path.abspath(__file__), as you'll see from the
large comment that tries to explain what's going on!
Bug: chromium:1166108, chromium:1166572
Change-Id: Ia0b19ff8956b2ede2447530be57876a88046887e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2631113
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This CL provides a script that generates a dark mode stylesheet for a
given sheet, just like the runtime color patching (in fact, it uses the
same code!).
The script loads up the given CSS file, imports `ThemeSupport`, and
patches it. It then takes the final CSS file and prefixes
`:host-context(.-theme-with-dark-background)` to each selector. We can
then load the lightmode and the dark mode stylesheet into DevTools.
This is non ideal because we end up loading two stylesheets, but the
alternative is to maintain the runtime color patching for ever, or
update all third party stylesheets to use our CSS variables, which is a
lot of work.
The script does rely on the hosted mode server running but I think this
is reasonable; it's only going to be run rarely on a few CSS files, so
we won't be running it automatically on CI or anything so we can keep
the process fairly manual.
Bug: 1152736
Change-Id: I707c53fbccb3e03c9fac6691f40df32bcdb17c1f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2587024
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
depot_tools ships a "vpython" binary that is added to the $PATH
for all Chromium engineers. This binary is versioned by depot_tools
which we roll in ourselves as part of `gclient sync`.
By using `vpython` instead of `python`, we are no longer depended
on the Python version installed locally and instead use the version
we pull in from DEPS.
R=liviurau@chromium.org
Change-Id: If49a54c24b6cf129ff843cd9ca1140a723a78afb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2571462
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This CL introduces the infrastructure and first test for what we're calling
"Interaction tests". These are tests that can be used to test component
behaviour that cannot be tested via Karma unit tests but don't require an e2e
test either.
The best example here is complex user interactions: clicking and dragging a
mouse, or doing multiple tabs to navigate through the UI.
Note that the one interaction test added here for theme_colors isn't the best
example of a complex test, but it's a test that's good enough for now whilst we
get everything set up on infrastructure and make sure it runs without flaking.
Bug: 1153281
Change-Id: Ifb37639a557c459974f703b8954ae68a93d5d368
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2566808
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
A recent TS config change elsewhere had caused these tests not to
compile with the error of:
```
error TS6307: File '/Users/jacktfranklin/src/devtools/devtools-frontend/scripts/component_bridges/value_for_type_node.ts' is not listed within the file list of project '/Users/jacktfranklin/src/devtools/devtools-frontend/test/unittests/scripts/component_bridges/tsconfig.json'.
```
The fix is to mark the dependency from the unit tests as a TS project
reference, and then generate output in the same place as the source, so
that import paths don't need to change.
This isn't ideal, and we would use ts_library if doing this now, but
this code pre-dates ts_library and also is only going to be around for
the length of the TypeScriptification work, so it doesn't feel worth the
effort to restructure it.
Change-Id: I9a924bf3e2ed945dd22ce233eda2c8c15f3193c6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2466188
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
We are building the :front_end target when files change, but this
doesn't seem to be broad enough to ensure we build on all changes. This
CL updates the target to devtools_frontend_resources, which does seem to
be a broader target.
This CL also includes a drive-by fix so that the output is sent to
stdout.
Bug: 1098694
Change-Id: I1d02cc0226767377aa4729af3cf3a734ec774026
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2278471
Auto-Submit: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Since we are moving to running from built content in the gen/ directory,
we need to have a watcher to ensure convenience for anyone working on
the codebase. This CL introduces a watcher that calls autoninja whenever
a file is changed in the front_end folder. It also updates node.py so
that it outputs the contents of stdout and stderr when the --output flag
is set.
R=tvanderlippe@chromium.org
DISABLE_THIRD_PARTY_CHECK=Updating node alongside relevant changes
Bug: 1098694
Change-Id: I4ddb3d250d0fd80455ea24e95055de74b2be879c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2272559
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
The node.py script does not currently output stdout or stderr, which for
ninja-based work makes total sense. However, when using it in more
general contexts (including debugging), having access to stdout and
stderr is useful. This CL allows the addition of --output as the first
argument to node.py, which, if found, will disable the piping of stdout
and stderr, allowing the developer to see their contents.
DISABLE_THIRD_PARTY_CHECK=Update package.json in line with node.py
Change-Id: Icfdd5479a391539dcf8b17e8d2180b5223ee1ea8
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2273180
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
The e2e-tests now use the build output in resources/inspector in
the out directory. This allows us to introduce TypeScript-authored
files in the source directory `front_end`, which will get compiled
into resourc/inspector.
After to making a change to a e2e-test or the front_end, you need
to rebuild Devtools, after which you can run `npm run e2etest` as
normal.
Since we now use the build output, this also means that you can
run the e2e-tests on the release build. In other words, if you
build DevTools with build optimizations (such as Rollup), the
e2e-tests will now use the output (and thus provide test coverage).
DISABLE_THIRD_PARTY_CHECK=Node fixes
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Fixed: 1088463
Change-Id: I02ec3c2476bc3647158fede9e1d347963b3a720a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2224809
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jose Leal <joselea@microsoft.com>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This significantly speeds up Karma execution times to about 12 seconds on an unchanged build folder.
It uses the Ninja build output to find the unittest files.
You can run the new script with:
npm run unittest
npm run unittest -- --target=Release
To make sure you perform a minimal build and run tests right after it, run:
npm run auto-unittest
npm run auto-unittest -- --target=Release
If no ninja-build-name is set, it assumes that `out/Default` exists.
The `auto-unittest` command will run autoninja for you on the output folder.
R=jacktfranklin@chromium.org,aerotwist@chromium.org
No-Presubmit: true
Bug: 1061125
Change-Id: I45edd11e422c5cdc8a4fc0bbb6bc43e386519aa9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2102717
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Brandon Goddard <brgoddar@microsoft.com>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Alex Rudenko