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>
This CL lints that for a given component that all the references to
its tag name are the same.
```
class Foo extends HTMLElement {
// Check that this name
static litTagName = LitHtml.literal\`devtools-foo\`
}
// And this name
ComponentHelpers.CustomElements.defineComponent('devtools-foo', Foo);
declare global {
interface HTMLElementTagNameMap {
// And this one are the same
'devtools-foo': Foo
}
}
```
Bug: 1153077
Change-Id: I29694449cb37950d1a5ff5391779e16e462926e2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2897279
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This CL updates our ESLint rule for custom event names:
* It changes it from wanting kebab-case to allonewordnopunctuation
* It allows references to CustomEvent.eventName for times when it's
useful to define the event name as a static.
The CL therefore updates a variety of events through the codebase that
were kebab-case. go/building-ui-devtools has also been updated.
Fixed: 1176758
Change-Id: Ifbe9851bc2f6bbe9347ec886cc8c026248cc5c43
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2894389
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Currently, all Protocol type definitions live on the global scope.
Additionally, the protocol files are included in all ts_library
targets. However, we don't want the protocol definitions to be
available in, for example, reusable UI components.
Therefore, we should move to a system where all files that want
to refer to the protocol types should import them instead.
However, doing so in 1 large CL will be problematic, which is
why it should be both globally available and importable as an
interim step.
To do so, we augment the existing protocol definitions to export
them as namespace and regular export. Then, we introduce a separate
file that imports the protocol types and augments the global scope
with the definitions. Now, protocol is both importable and remains
available on the global scope.
The reason that we need a separate file is that TypeScript disallows
you to augment the global scope in a file that also exports types.
Therefore, the global scope augmentation happens in protocol-globals.d.ts,
which will be removed once all Protocol type usages are imported.
To verify that this approach works, ProtocolClient imports the
required types, while SDK only imports it in AccessibilityModel.
All other files in SDK still refer to the global type.
In follow-up CLs, all pre-existing usages of Protocol will use
the import style.
DISABLE_THIRD_PARTY_CHECK=Updating protocol type format
R=szuend@chromium.org,jacktfranklin@chromium.org
Bug: 1208357
Change-Id: I1d75949b9cd3e37989c6cddf79ac849f5664a1e3
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2891756
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This CL adds an ESLint rule that bans the use of:
```
LitHtml.html`<devtools-foo>`
```
Because from now on we want to enforce:
```
LitHtml.html`<${Foo.litTagName}>`
```
I have disabled the rule in all locations where we do not yet do this,
and will be working to fix these problems over a series of CLs.
Bug: 1153077
Change-Id: I8d18243d0243ea1403d5d57dbeb32c8a9682d2dd
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2876969
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This script can be invoked to obtain the coverage from the unit
and interaction tests and writes them to a coverage-summary.json
file that lives in `test/`. This file can then be used in favor of
karma-coverage/coverage-summary.json to upload to the Chromium
infrastructure.
As a follow-up, we should turn on coverage collection on CQ and
hook up this script after both unit and interaction tests have
completed.
R=jacktfranklin@chromium.orgCC=liviurau@chromium.org
Bug: 1206705
Change-Id: I52199940d6747ec13f208233e04dcf81a618a8fb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2884240
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
All interaction tests are now lazily instrumented with Istanbul
to obtain code coverage. The interactions tests can be started
with `COVERAGE=1` to obtain coverage. For that, the Mocha hooks
perform the eventual reporting and gathering of data. The instrumentation
is performed in the components server itself.
To make sure that we perform the minimal amount of work required
(since code coverage instrumentation is computationally expensive),
we preload pages to populate the instrumentation cache. Every
interactions tests should preload an example (most likely basic.html)
to populate the cache. Every subsequent test will then use the
already-instrumented code, rather than computing the code over
and over again.
The eventual code coverage is written to /interactions-coverage.
The results will eventually be merged with /karma-coverage
to obtain the union of both unit and interaction tests coverage.
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1206705
Change-Id: I5e19b1ecef23d21107210699cb29800556e0415e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2879986
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Tim van der Lippe