Lexical declarations in `case` and `default` clauses are a footgun,
since they are visible in the entire switch block, but they only
get initialized upon assignment, which only happens if the relevant
`case` is actually reached.
To ensure that such lexical declarations only apply to the current
`case` (which is usually the intention), `case` clauses containing
them should be wrapped in curly braces to create an explicit block.
More information:
https://eslint.org/docs/rules/no-case-declarations
Change-Id: I63d9341fcd76d4b9ce8281bd0e6573b886577f08
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2119685
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Commands, Events and Object types can declare "inline enums" to
restrict the possible values of a 'string' field.
Example field:
referrerPolicy: ('unsafe-url'|'...'|'...')
To enable type-checking with TypeScript and stay compatible with
existing code, we now generate explicit enums. The naming scheme
for the enum names is adapted from code_generator_frontend.py
and needs to always match.
Example generated enum for the above code:
export enum RequestReferrerPolicy {
UnsafeUrl = 'unsafe-url',
NoReferrerWhenDowngrade = 'no-referrer-when-downgrade',
NoReferrer = 'no-referrer',
Origin = 'origin',
OriginWhenCrossOrigin = 'origin-when-cross-origin',
SameOrigin = 'same-origin',
StrictOrigin = 'strict-origin',
StrictOriginWhenCrossOrigin = 'strict-origin-when-cross-origin',
}
This is necessary as we didn't had any type for this enum before
but existing code was using
Protocol.Network.RequestReferrerPolicy
as a type in JSDoc.
R=tvanderlippe@chromium.org
Bug: chromium:1011811
Change-Id: I4b4aa04b69fa4d7bf3b79ad97d61d4e3bfb7e228
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2113374
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Instead of
export type MixedContentType = ('blockable'|'...'|'none');
we know emit
export enum MixedContentType {
Blockable = 'blockable',
OptionallyBlockable = 'optionally-blockable',
None = 'none',
}
This is necessary as existing JavaScript code accesses these
enums using
Protocol.Security.MixedContentType.None
R=tvanderlippe@chromium.org
Bug: chromium:1011811
Change-Id: Id4bf2c1333affcdc4df37a43bf95379700e3e9d0
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2113373
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
front_end/Runtime.js was doing multiple things: it was instantiating
side-effecty descriptors and initializing applications, as well as
storing all state for the modules/extensions, etc...
To support proper ES Modules, we need to separate these. root/Runtime.js
contains simple classes that store the data and can be retrieved, as well
as some helper functions that will load the respective data.
The RuntimeInstantiator.js code includes the start functions used in the
entrypoints themselves. They will use an instance of the Runtime to
properly load the application.
Along the way, I also fixed various TypeScript errors, mostly around
incorrect or missing type definitions.
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1011811
Change-Id: If3ddea9267813691b3faeb6ea4b0cf64edbde1f4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2107523
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This CL changes references to self.Common.settings (the global
instance of SDK.Common.Settings) over to
Common.Settings.Settings.instance(). To keep both TypeScript and
Closure happy we must make a method on the Settings class itself,
since it only allows private constructors to be accessed by static
methods on the class.
Bug: 1058320
Change-Id: I04afc8caf64acf29cdda13ef03ad05cfff4786a1
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2091450
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: 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>
For most of the PRESUBMIT invocations, the CL in question does not
change anything with regards to ESLint. Therefore, we can skip doing the
full check and only perform the check on relevant JavaScript and
TypeScript files.
However, if we do change the ESLint configuration (via one of the
involved build scripts/configuration files), we should run the full
check to make sure we are compliant.
`npm run check-lint` will still run the full lint check.
This saves about 15 seconds on a regular PRESUBMIT invocation, scaling
with the number of files changed.
R=jacktfranklin@chromium.org,aerotwist@chromium.org
Change-Id: I9c1bb055274bfa1d8cc47c9039a1196c92eba399
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2097993
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
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>
(Initially made this change on the breadcrumbs CL but pulled it out).
In the components TypeScript world we want it to be really easy and
obvious which function to use for localized strings. We agreed that `ls`
is the best option.
Right now not all of `Common` is TypeScriptified and that means that
from a TypeScript file you can't do `import * as Common ...`. So to get
around this we create a new module, `Common/ls.ts` which literally
re-exports `ls` from `Common/UIString`.
We then update the ES modules importing rules to special case that:
1. IF you are in a TypeScript file
2. AND the import ends in `common/ls.js`
3. then it's OK - else you have to stick to the usual rules.
I'm sure this will change over time as we migrate more to TypeScript and
build more components but this is a good starting point for enabling
easier localization from TypeScript components.
Additionally we can swap the export in `common/ls.ts` out for a newer
one if we decide to change how it works without changing all the
callsites.
Change-Id: I226525b2e606cf70a50ef37a4d17aa37b18a34ab
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2097978
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This plugin needs to be used to write our own custom ESLint plugins that
live in our repository. It replaces the `rulesdir` CLI option, as the
solution of putting it in `.eslintrc.js` is compatible with code editor
plugins.
I also discovered that we were incorrectly running clang-format on
`node_modules`, as I recently fixed the PRESUBMIT. To make sure that
doens't happen again, add a `.clang-format` that disables the formatting
in that folder.
DISABLE_THIRD_PARTY_CHECK=Add new node_module
Bug: 1060123
Change-Id: Ib2c0d23f499604deeea51cb06192bce3a7aa89af
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2096449
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This CL introduces support for parsing and pulling translations out of
`*.ts` files.
It introduces code to parse a TypeScript AST to look for `ls` calls and
pass them back into the existing GRDP tooling.
As a purposeful limitation, it _only looks for `ls` calls_.
Change-Id: I3f91793165e11f0382d6266f4e2c2443701b299a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2095295
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Settting the Ninja arg `is_debug` will retain the old behavior. However,
setting that flag to `false` will start using Rollup. Rollup will bundle
everything into an entrypoint, but will avoid bundling module
dependencies.
For example, if a file in `ui` depends on `common`, then everything in
`ui` will be bundled into `ui/ui.js`. But, it will retain all imports to
`common` as `import * as Common from '../common/common.js';`.
This also caught an issue with misconfiguration in the
wasmparser_worker, which should import the files directly and can't use
it in the dependencies array of the module.json
Lastly, the BUILD.gn definition is significantly cleaned up. In the
process of doing all this work, I discovered that we can simply use
`foreach` to iterate through all source files. This removes the
duplication of both `fron_end` and `$resources_out_dir` and
significantly reduces the amount of clutter in BUILD.gn.
As such, update check-gn.js to check for the correct GN variables.
roll CodeMirror: ignore
Bug: 1046596
Change-Id: I7dcda7949e79e001c8a11307dc902f96a8fa6696
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2089906
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>
Tim van der Lippe