It is possible for TypeScript to import a file that is not included in
the corresponding devtools_entrypoint as a dependency. In many cases
this would likely cause the build to fail, but it's also possible that a
dependency might have been provided as a dep of another entrypoint.
Given that ninja parallelizes builds this results in a race condition
where on some builds the dependency that wasn't declared is there, and
on some builds it is not. This is further complicated if build artifacts
from previous builds are kept around.
This CL introduces a script that can be run manually that cross
references the files that GN knows about, and the files that TypeScript
expects to be able to import. Any files expected by the TypeScript
compiler that are not declared in the BUILD.gn (even indirectly as a
dep of a dep etc) will be flagged.
Change-Id: Ieb95600f11bfc20e0e71d8792a7f344b13a0fb8e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2316063
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
The internal ninja copy action is, for Linux and Mac, the creation of a
hardlink. In the case of an is_debug = false build, we copy the
devtools_entrypoint file with ninja to the gen folder. However, should
the file then change in the gen folder, those changes will be reflected
back in the original source file since the two are hardlinked. This does
happen when the JavaScript file moves to being managed by the TypeScript
compiler, for example, because tsc often changes blank lines and adds
sourcemap information to the file. If the gen folder is empty and no
hardlink exists prior to build, there are no issues. If, on the other
hand, the hardlink exists, and the TypeScript compiler runs, the file
written in the gen folder will update, and then so will its original
source.
The ways to resolve this reflection back to the source folder is either
by deleting the gen folder before rebuilding (where one anticipates
changes being reflected in source), or, instead of using the ninja copy,
using an action to call out to a script that will ensure that a new file
is created and not hardlinked.
This CL chooses the latter path.
Change-Id: Id2cc8acdc240eb73ac736ddaf6f1eabdd08f8359
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2308534
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This CL ships the new elements breadcrumbs component to production,
replacing the old legacy breadcrumbs with the new custom element that
we've built to replace it.
Note that I haven't renamed the file from `NewElementsBreadcrumbs`. I wanted to
keep the diff on this CL clear and easy to follow. I plan to follow this up
with another CL that does the renaming.
Light mode & dark mode screenshots: https://imgur.com/a/UyF4ktY
Change-Id: I5c3df09456101ce03072f3eeb27f6a1c568cf9c7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2297395
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Required changes:
- Add CodeMirror types as globals
- Add support for `is_web_worker` in `ts_library` and
`devtools_module`, as the FormatterWorker is a worker. This
also moves the `lib` specification out of `tsconfig.base.json`,
as we now need to dynamically generate it
- Fix (seemingly unrelated) issues with untyped events in other
files. I don't understand why TSC suddenly started to complain
about these.
DISABLE_THIRD_PARTY_CHECK=TypeScript fixes
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1098730
Change-Id: I7d33c22983f2fe5e793c20fa5d56411d996ec999
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2294985
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Sometimes in devtools we want to take a file directly from sources into
the `resources/inspector` folder, and other times we want to move files
from `out/Default/gen` into `resources/inspector`. Rather than have one
command for both of these and do nasty path wrangling to put the files
in exactly the right place, we instead split them into two templates.
This is nasty but our hope is we can hide this complexity behind other
templates that most people will use; this shouldn't be used directly by
people very often.
Change-Id: I3e7acbbed0c6d1bb8ad69a62cbe7341ad856d98b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2287517
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
For folders that already have a `devtools_entrypoint` target, we
should skip Rollup as part of `build_release_applications.py`. To
remove the hardcoded list of skipped folders and enable
parallelization of a fixit to migrate all folders, we have to put
the information in the `module.json` instead.
Once all folders are migrated to `devtools_entrypoint`, we can remove
the field and the Rollup logic in `build_release_applications.py`.
R=aerotwist@chromium.org
Bug: 1101738
Change-Id: Ibadab13e87cf28622c40896a56f6ed18cc34bea2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2284838
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Rather than hardcode the port to use, use port 0 which
requests any free port from the OS. We report the port
we end up using to the caller over IPC, if an IPC
channel was opened by the caller.
We wait for the port to get reported before starting
the chrome instance.
Previously we started the hosted mode server and then
started chrome without waiting for it to start. This is
probably fine in most situations because chrome takes a
while to start and we need to do extra setup there, so
we have a long time before the server needs to respond.
For parallel test mode, we need to make sure we start
the server on a free port. This also makes the mocha
runner more robust to failures e.g. if we accidentally
leave the server running and the port is taken.
This doesn't slow down the startup time of the e2e
test runner at all, according to timing of local runs.
Bug: 1101784
Change-Id: Ibb14d5a177ba5f9e257743824770bff3d5ccb033
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2285124
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This CL fixes a number of bugs that we discovered in the bridges
generation. Some come as a result of breaking AST changes in TypeScript
4, and others are a result of using TS features in the components code
that we haven't used before and therefore the generator code needs
updating accordingly.
The list of changes are:
* Dealing with `Readonly<X>` and `ReadonlyArray<X>`, discarding the
wrapper type and parsing the inner type.
* An update to the null checking code as TS4.0 changed how `null`
literals are represented in the AST.
* Update the generator tree walker to avoid trying to parse `import * as
...`.
* Error nicely if we detect an interface being referenced as `Foo.Bar`.
We only support referencing interfaces directly.
Change-Id: I2faf314d28281863b2ad9e1695cde8ff60014ead
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2284825
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Changes include:
- Test server handles URLs with escaping better.
- Logging from DevTools frontend now logged by the test.
- Helper to turn on CDP logging - for debugging only.
- click helper improved to allow specifying maximum distance from
left, for when an element extends far beyond its containing
element.
- New pressKey helper that makes keyboard shortcuts easy.
- Helpers to modify and save a source pane and to get the text of
the line of code where we are stopped.
Bug: 1094436
Change-Id: I389eaa680bb0771a45104f470647f67b4fa5d1d9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2282811
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Eric Leese <leese@chromium.org>
This introduces the first TypeScript-authored file that also makes
use of TypeScript features. To do so, we have to perform several steps:
1. Move the `formatter_worker` typescript files into a new template called
`devtools_module`. This template takes care of running TypeScript and
copying the files it generates to `resources/inspector`. (The latter can
be removed when we are in a position to do so)
2. Move the files out of `all_devtools_modules` into (yet another) GN variable.
We should clean this up by using the `grd_file_group`, which is possible
with an integration with `devtools_module`. However, for simplicity's sake
I decided to fix that in a follow-up. The integration of `devtools_module`
with the GRD action script would then finally allow us to remove the duplication
of all of these file strings in multiple places.
3. To make sure that the buildgraph remains intact, we have to perform
the copy-step after the typescript-step. However, this means we need to use
a different name than `target_name` for the typescript compilation. We run
into issues there, as the project references assume that the names are the
full folder names (e.g. `../formatter_worker`). If we would then use a different
name for the `ts_library` action, then we generate a `tsconfig.json` with
the wrong name. To counteract that, introduce a (temporary)
`typescript_config_name` where we can explicitly set the name of the `tsconfig.json`
that we generate. This is not ideal and I am still thinking of a better
alternative, but haven't figured out a solution yet.
DISABLE_THIRD_PARTY_CHECK=Typescript fixes
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1098730
Change-Id: I1457067845cdedbc7d4ce6a80c12d7943b67087c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2282809
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Mathias Bynens
