This CL switches out the in-tree versions of en-US.json/en-XL.json
in favor of the versions generated at build time. They are identical.
The implementation is straight-forward. On the minification step, we
exclude the in-tree en-US.json/en-XL.json and instead add the
outputs of the "collect_strings" action (aka the generated en-US.json/
en-XL.json).
R=kimanh@chromium.org
Bug: 1185727
Change-Id: I923fba50033305a7df6bedccf65c657ecc8e5235
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4043247
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
This CL adds a `--log-level` flag to the unit test runner that will
allow the log level to be configured. This flag is passed right through
to Karma, but is also respected by the logs output by our test runner
before initialising Karma.
The default value for `--log-level` is `info`, so this CL doesn't change
the built in functionality; but you can now pass `debug`, `info`, `warn`
or `error` to configure it.
Bug: none
Change-Id: I82006a1a8283c3d93389f124317a37bac69b5038
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3963112
Commit-Queue: Thiago Perrotta <tperrotta@chromium.org>
Reviewed-by: Thiago Perrotta <tperrotta@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
There are a couple of code changes for us that are relevant:
1.The accuracy of `lib.d.ts` (DOM definitions) has improved, so we have
to update a type in `Button.ts`. This changes the type from
`X|undefined` to `X|null` so this is very minor.
2. TypeScript got better at understanding conditionals that will always
return `true`, and caught a case where we were doing:
```
addEventListener(e => e.key === 'Enter' && Common.Revealer.reveal(...)
&& false)
```
TS errored because the `reveal()` call is a promise and therefore will
always return true, causing the entire expression to return the final
`false`. Returning `false` from an event listener doesn't do anything,
so I've removed it.
DISABLE_THIRD_PARTY_CHECK=required updates to land TS upgrade
Bug: none
Change-Id: I89ab2ad730d40308da173bd7788c17daf0b4a511
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3757623
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
This CL disables formatting within the `generated` directory, which is
all code that is programatically generated. Previously we disabled
eslint for `protocol.ts`, but now we are being consistent and disabling
it (and clang) for all files.
I also re-generated the files in the generated folder, so we avoid any
confusion if/when the generated scripts get re-run and suddenly the
format drastically changes.
DISABLE_THIRD_PARTY_CHECK=changing generated files + config
Bug: none
Change-Id: I714ada8bf7d85020e3be71b35c9db98840bf3ef2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3755163
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
In crrev.com/c/3748106 we noticed that a CL was able to land that
imported a file without the `.js` extension.
This is because `.eslintignore` listed `front_end/third_party`, so that
folder wasn't linted at all. This is an issue because whilst most of the
code in that directory is not authored by us, the entry points usually
are, and we want to apply our lint rules there.
This CL removes the blanket ignore, instead preferring to ignore
`third_party/X/package/`, and a few other special cases, ensuring that
devtools-frontend authored files in `third_party/` do get linted.
The CL updates the `es_modules_import` rule to not apply the import
checks to files in `third_party` (as they cannot apply the same
conventions we use in DevTools), but it will still check for file
extensions on imports.
The remaining changes are small stylistic changes to align to our ESLint
rules.
Fixed: 1342530
Change-Id: I4ce438499b8c9c77c3fe661576a58bad59d9b061
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3749191
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
I had an issue where I'd copied/pasted a component definition but
forgotten to change the litTagName property. I then realised that this
rule wasn't detecting the case where we have duplicate `litTagName`
items and should be, so we now check if we've seen a tag before and
error if so. This ensures no duplicate tag names can exist in any single
file.
Bug: none
Change-Id: I2fe5bdfe3bee6a2d2f52e90f9b80e5c82737f416
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3702263
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Currently calculating the path to chromium's root directory returns an empty string on Windows because the path used to compare against the executable path is not normalized.
```
PATH_TO_EXECUTED_FILE.indexOf(devtoolsPath)
```
Becomes
```
'D:\\drive\chromium\src\third_party\devtool-frontend\src\...'.indexOf('src/third_party/devtools-frontend'); -> -1 on Windows
```
The fix is to use the normalizedPath variable to return the correct substring.
Change-Id: Ia12232f3746466f3257975d652342ac8b9ed2578
Bug: none
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3703315
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: John Emau <John.Emau@microsoft.com>
This CL introduces support for writing inputs to wasm tests in wat
format. This will allow removing dependencies on opaque binary resources
that can't be regenerated without changing hardcoded offsets in all
tests. Referencing binary and/or source file offsets will now be
possible through special comments left in the wat source.
Bug: 1328729
Change-Id: I6369c86ca57860fd9803b894797f63c36c65d554
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3666419
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
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>
Simon Zünd