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>
The `preinstall` hook is problematic for users trying to `npm install
chrome-devtools-frontend`. For DevTools development, it’s not
directly needed since `npm run install-deps` is supposed to be used
instead of `npm install` anyway.
Therefore, this patch removes the `preinstall` hook.
Bug: chromium:1066415
Fixed: chromium:1058161
Change-Id: If7fccf2ed392ec47bf79e55470a0fd3cc5a8b880
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2144091
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This allows us to execute the following:
npm run install-deps -- outdated
Which is equivalent to `npm outdated`, although it will run on the
actual node_modules output (that we can verify is unchanged).
Most of the npm commands require the private information to exist.
Therefore, if we run a custom command we first have to install with
`npm ci` to get the private information. Then we have to execute
the command, perform the cleanup and only after that finisht the
script. If we would bail out right after executing the custom command,
the private information would remain in the repository.
R=jacktfranklin@chromium.org
Fixed: 1068132
Change-Id: I50d3538a7115783dea19e1899faf17b1622f22ff
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2137381
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
We now check that the build_output.txt is equivalent to the build_output.txt.expected.
This includes compilation failures, which `compilation_failure_front_end` shows.
To be able to have machine-agnostic buildoutputs, the toolchains need to be
absolutely referenced and thus every fixture needs the same copy of a toolchain.
Also, the ts_library print must use the relative path rather than the absolute path.
R=jacktfranklin@chromium.org
DISABLE_THIRD_PARTY_CHECK=Add ts_library tests.
Bug: 1064287
Change-Id: I4a4db566cc155b7f6e73cadc2efcfa8d615286ed
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2118097
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
These files were used in the pre-ES module module era, to instruct
editors like VS Code to resolve symbols. However, since we are in ES
modules land we explicitly *don't* want this resolution. By removing
suport for jsconfig, the editor will now warn before hand on un-imported
symbols. This should reduce the risk of accidentally using the global
symbol rather than the import.
After this change, there will be numerous `jsconfig.json` in the
repository. You are recommended to `git add . && git reset --hard` to
remove these from your local checkout.
Most files will now see a lot of red squiggles with errors, which is to
be expected, as TypeScript does not understand many of the globals. I
have declared `ls` in the globals to at least suppress these, as well as
fix the definition of UIString. These seem to be the most prominent.
All other usages will still need fixing before the files in question can
be typescriptified. However, we do hope that with this change, it is
more difficult to check in new code that is not compliant with
TypeScript already.
Bug: 1006759
Change-Id: I6591e73d66c845a2160b843b627c1adcb1389c24
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2098602
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Robert Paveza <Rob.Paveza@microsoft.com>
This improves the PRESUBMIT performance as we can rely on the AST
parsing of ESLint, meaning we don't have to parse AST twice.
It also allows us to use the nice `--fix` solution to insert the proper
license header in the files.
This shaves an expected 5 seconds of the presubmit time
(non-scientifically computed based on 2 uploads).
Change-Id: I5c53e9b232585f9ec46f86b36557c50bf80f7add
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2097992
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Jack Franklin