During my work to update JS import wrapping, I wrote up a hacky script
to auto-run clang on all JS and TS files. This CL is that script, but
tidied up and made a bit neater. I think it's worth landing as I can
easily imagine us needing to use it again in the future if clang
releases new config options we want to apply.
Bug: none
Change-Id: I43240c0ffab912d77950cb76540ccdfe8fed556c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3627330
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
We have a common pattern in our codebase where a function might return a
lit template, or the result of `Lit.nothing` (which is equivalent to
`{}`). Therefore we have a fair amount of code that looks like:
```
foo(): LitHtml.TemplateResult|{}
// or
foo(): LitHtml.TemplateResult|typeof LitHtml.nothing
```
I'd like us to be consistent over which we prefer, but also this feels
like a little bit of an implementation detail that's leaking out - to a
person using our components system, a Lit template result or `{}` are
really equivalent - and we shouldn't have code that cares.
Therefore I'm proposing we expose (this will be done in a separate CL):
```
type LitTemplate = TemplateResult|typeof nothing
```
And then use this ESLint rule to:
1) update existing code to use the new type
2) ban future code from not using the new type
Both of those steps will also be done in a follow-up CL, this CL
introduces the basic rule.
Bug: 1320753
Change-Id: I2f3d5029a695922c9a71334e34259597eaebfcc0
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3613881
Commit-Queue: Andres Olivares <andoli@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Andres Olivares <andoli@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
This rule is able to merge imports such as:
```
import type {Crumb} from './breadcrumbs.js';
import {BreadcrumbComponent} from './breadcrumbs.js';
```
Into:
```
import {BreadcrumbComponent, type Crumb} from './breadcrumbs.js';
```
It can also inline standalone type imports:
```
import type {X, Y} from './foo.js';
```
Into:
```
import {type X, type Y} from './foo.js';
```
Note: this CL only lands the rule and does not enable it.
Bug: 1319340
Change-Id: I0f7d9e8a6833f836a0e4581d68ee7fd1b27c0edc
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3605262
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This CL introduces (but does not enable) an ESLint rule to check that if
a Lit component renders a checkbox, that it also imports and adopts the
common `Input.checkboxStyles` into the component's shadow root.
We can also roll this rule out to the text inputs too, but I wanted to
start with just one and see how it goes. I will follow up this CL with a
CL to enable this rule.
Bug: 1316297
Change-Id: Ibed7109d5948c8be3f4c9d376738290137e444ff
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3586906
Reviewed-by: Johan Bay <jobay@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
This CL changes e2e tests to load the DevTools frontend on the
'devtools-frontend.test' origin instead of using 'localhost'.
'localhost' is used by the target page. If we also load DevTools via
'localhost' than the two pages share window.localStorage and are
considered "same-origin", which hardly reflects reality.
To enable this CL, we have to change the hosted-mode server to set
some CORS headers. More specifically, we allow the DevTools frontend
to request arbitray resources from the hosted-mode server, while
target pages have to be explicit in their ".headers" or
".rawresponse" files.
The CL also rebaselines a couple of e2e test that expect exact
response sizes or expect exact response headers.
R=jacktfranklin@chromium.org, pfaffe@chromium.org
Bug: 1297458
Change-Id: Ie18069e2effcc53cfd10a19296dc5d5c74b40e17
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3467975
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
This CL adds the ability to run:
```
npm run auto-unittest -- --mocha-fgrep=breadcrumb
```
To the Karma unit test suite to mirror the similar flag available in the
interactions and e2e test runner script. This is also why it's named
`fgrep`, as that's the same flag as used in the other script, and we
should be consistent.
Bug: none
Change-Id: Ic119f7186e0e97c83e00bf92a66d69181c931a8b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3452723
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim Van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Tim Van der Lippe <tvanderlippe@chromium.org>
Use fast bundler if typecheck is skipped, assuming builders/developers
want to get result faster in such build config.
This will also remove the necessity of having devtools_fast_bundle
config from chromium CQ/CI's build.
This is step 6 of http://go/devtools-fast-bundle
Bug: 1278663
Cq-Include-Trybots: luci.devtools-frontend.try:devtools_frontend_linux_blink_light_rel_fastbuild,devtools_frontend_linux_dbg_fastbuild
Change-Id: I516b0af30c8c76c9382dfa09763d4efb8d1bdae7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3429380
Reviewed-by: Tim Van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Auto-Submit: Takuto Ikuta <tikuta@chromium.org>
Proposal: http://go/devtools-fast-bundle
This CL introduces build flag switching bundler from rollup.js to
esbuild by
* adding esbuild to npm without downloading binary packages
* making devtools_plugin for rollup.js re-usable to esbuild
On 24C/48T Z840 Linux machine, this shows following performance
difference by using
```
devtools_skip_typecheck = true
is_debug = false
```
as base build config.
esbuild (devtools_fast_bundle = true)
$ time ninja -C out/Default/
...
real 0m21.174s
user 2m47.513s
sys 0m38.549s
rollup.js (devtools_fast_bundle = false)
$ time ninja -C out/Default/
...
real 1m28.286s
user 30m19.220s
sys 5m36.392s
So esbuild is 3.2x faster and use only 9.6% of machine resouce
(user + sys) compared to rollup.js.
refs:
* https://esbuild.github.io/plugins/#on-resolve
* https://rollupjs.org/guide/en/#resolveid
Bug: 1278663
Cq-Include-Trybots: luci.devtools-frontend.try:devtools_frontend_linux_blink_light_rel_fastbuild,devtools_frontend_linux_dbg_fastbuild
Change-Id: If6b2e774f48091b0fe9c959e7ed1ed9bc2b0847c
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3401984
Reviewed-by: Tim Van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
This is to make const enum in protocol.d.ts works with esbuild in
unittest.
Without this, const enum usage from protocol.d.ts is not replaced with
esbuild. So I need to make protocol.d.ts actual TypeScript file and make
it has corresponding JavaScript file with defined enums.
I also need to tweak how protocol.js is imported to make build/test pass
in both tsc and esbuild with child CL.
Bug: 1278663
DISABLE_THIRD_PARTY_CHECK=change generated/ and importing files
Change-Id: Ic5f27633c85bbfe8647636beef9b8625f33eabdd
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3367593
Reviewed-by: Tim Van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Randolf J