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>
`recordEnumeratedHistogram()` needs both the actual bucket and the total
number of buckets. The total number of buckets was previously determined
by `Object.keys(someMap).length`. This prevented us from ever removing
keys from `someMap` since its length would change.
By explicitly adding a `LastValidEnumPosition` we can now safely remove
keys.
Bug: 1278403
Change-Id: Ib256fc2cf54123f596aa9c5525cce2aabe28bec0
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3329541
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Wolfgang Beyer <wolfi@chromium.org>
Previously, we exempted our unit tests from importing only entrypoints.
However, we later realized that we always have to import the entrypoint
to avoid build non-determinism problems. Therefore, remove these exemptions,
which incidentally caught some existing violations.
The ColorUtils file is special in inspector_overlay, so we can safely
exempt that one as a one-off. The e2e-test need to import the helpers
as all other e2e-tests do. The hello-world is an example, so let's ignore
that one for now.
R=jacktfranklin@chromium.org
Bug: 1271490
Change-Id: Ib05d799b547e46cde4349b8738a5ecd63d50f3e1
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3291160
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
To remove the module.json file in perf_ui, we need to migrate the
resources to the new `generate_css` template. However, perf_ui is a bit
special, in that it doesn't properly use the widget structure. As such,
it sometimes injects CSS in places where there is no clear shadowRoot
available. Therefore, it is not possible to migrate to CSSStyleSheet in
combination with adoptedStylesheets.
As a workaround (to unblock the module.json removal), we augment
`generate_css` to add legacy file generation. All remaining resources in
DevTools will migrate to these `.css.legacy.js` files. That's because
these resources either are special (perf_ui) or are used in the
`device_mode_emulation_frame` which can't use `CSSStyleSheet` itself.
The files export an object, rather than a plain string. That's because
we need to be able to distinguish what string is referencing a CSS file
path and which strings contain the actual CSS styles. By using an
object, we can remain using the `typeof` check for string in the legacy
CSS infrastructure and otherwise destructure the object.
After this, we can remove perf_ui from the module.json structure and
properly bundle+minify the CSS resources.
R=jacktfranklin@chromium.org
Bug: 1190991, 1127902
Change-Id: I7523333e8025ae5fe5ed74b99b4e45907ff9ad97
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3275787
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>
Historically, we special-cased importing the legacy utils, as
Rollup would eagerly roll them up in a single bundle. However,
since then we changed the Rollup heuristic to always assume that
a different folder is a different entrypoint, including sub-folders.
As such, we are no longer including entrypoints of sub-folders in
parent folders.
However, utils was special-cased and was importing the direct files.
This normally isn't a problem, except for the fact that the
devtools_entrypoint of `ui/legacy:bundle` would now bundle the sources
of `ui/legacy/utils`, but wasn't rebuilding when it needed to.
Therefore, change the utils to a proper sub-folder and avoid the
special-casing. Since we no longer have a circular dependency
between the utils and `ui/legacy`, we can safely make this change.
The ESLint rule has also been updated to make sure we don't regress
in this area again.
R=victorporof@chromium.org
Fixed: 1148274
Change-Id: I020622c5790041d5f676bee2ef883ff0ece76695
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3148370
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Victor Porof <victorporof@chromium.org>
Reviewed-by: Victor Porof <victorporof@chromium.org>
and fixed duplicate entries in `devtools_grd_files`.
Some files import CSS files not in the same directory as them. The
script was currently unable to handle this case and so migrations led
to `File Not Found` errors for the `.css.js` files. The script now
finds the relative path from the imported file to the current file and
adapts the import statement correctly.
Duplicates were being added to `devtools_grd_files` which led to errors
during the build. The check now verifies the entire file path is
contained in the GRD file to prevent duplication.
Bug: 1106746
Change-Id: I5da808a8885bc18477cfa31801a904e17924caab
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3059012
Commit-Queue: Kriti Sapra <kritisapra@google.com>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
`registerRequiredCSS`.
There are two main edge cases: multiple calls to
`this.registerRequiredCSS` and calls to properties of the object, e.g.
`this._widget.registerRequiredCSS`. I have added cases to the ESLint
rule to migrate these automatically.
In ESLint tests, the output is produced after only a single pass of
the rule. Keeping this in mind, the tests for multiple calls have
been broken down into multiple tests cases.
Bug: 1106746
Change-Id: If5a4827ec7230508c9208c6d23882499495be12a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3053744
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Kriti Sapra <kritisapra@google.com>
It adds `import componentStyles from './component.css.js'` for any
registerRequiredCSS('front_end/component/component.css') call.
It also checks if there is an existing `wasShown()` method. If this
exists then it adds an extra line to add the
`this.adoptedStyleSheets = [componentStyles]` statement. Otherwise,
the `wasShown()` method is created and added.
Bug: 1106746
Change-Id: I7d0244d129fe0f4a50432fd7b53135760ae304ae
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3043915
Commit-Queue: Kriti Sapra <kritisapra@google.com>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This CL prevents calls to i18nString and i18nLazyString without using
`UIStrings` as the first argument. While the rule is rather strict,
the few places where different usage is warranted, the rule can
be disabled.
The CL also fixes all call sites in violation by either updating
types, or disabling the rule.
R=tvanderlippe@chromium.org
Bug: 1180760
Change-Id: Ibef05525577fc6b4443c1f7ea69023f1bba828ef
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3041381
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Jack Franklin