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>
This allows us to add an npm command that does the same thing. This is
necessary to support the workflow of making changes in the pdl during
development.
You can regenerate the relevant protocol files with
`npm run generate-protocol-resources`. Note that the files it generates
are not formatted, but on presubmit it will both format and lint the
files to the correct notation. However, that should not impact the
workflow of making changes to the protocol files and testing their
behavior.
R=sigurds@chromium.org
Change-Id: I87c06183c8842d8643c4647cb1519850d75bd46d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2088093
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Jack Franklin