@typescript-eslint/no-inferrable-types Simplifies the code and makes
type be more specific.
@typescript-eslint/return-await In theory more performant, but also
provides better debugging experience.
@typescript-eslint/ban-ts-comment Disallow all but ts-expect-error, as
else the error may get fixed not remove and later mask unrelated issues
Bug: 397260638
Change-Id: I09f268eb9157336635c378fa76546a4196e448e9
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/6281149
Reviewed-by: Victor Porof <victorporof@chromium.org>
Commit-Queue: Nikolay Vitkov <nvitkov@chromium.org>
Auto-Submit: Nikolay Vitkov <nvitkov@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>
This CL uses a heuristic to classify identifier types:
If the type ends with Id or ID it is considered an
identifier type. The CL also introduces an override
in protocol_dts_generator.ts which can be used to
add more types, or disable the heuristic for specific
types.
DISABLE_THIRD_PARTY_CHECK=disable
Fixed: chromium:1226471
Change-Id: I4696463622ef026c48e1abeefd48aa438f9d11f6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3110425
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This uncovered a bug where we used a targetID to as a sessionID,
which is fixed in this CL. The bug caused target information to
not get updated and the fix should increase target information
accuracy.
DISABLE_THIRD_PARTY_CHECK=<reason>
Bug: chromium:1226471
Change-Id: I89e461381443617d96ae06d5775038cd32ad8dd1
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3080308
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This uncovered the fact that NetworkRequests really have two
request ids: One that is a string used in the front-end that
doesn't always have a corresponding request in the back-end,
and one that is always a back-end id. This CL makes this
explit in the types.
DISABLE_THIRD_PARTY_CHECK=disable
Bug: chromium:1226471
Change-Id: I894d6ab4d14099b9793c5e1c1a2863d2ec9c2548
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/3014857
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@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>
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>
Throughout this process we learned the following:
- The magically generated agents need to be properly exposed
on the target, rather than setting them on the TargetBase prototype.
- We need to rename the protocol proxy api definitions to use
the invoke_ naming, such that we can use structured request bodies.
This will allow us to no longer rely on parameter ordering and
does not require additional changes to the underlying Closure
generated code.
- Instead of using a symbol as an index on a different class, use
a WeakMap to keep track of the link between the NetworkRequest
and the NetworkManager. This breaks the circular dependency and
allows us to remove the lookup with the symbol
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1011811
Change-Id: I6cf25533b32793636d970b0a6c108f739d4e757e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2167868
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Even though we were using the SDK files in the unittests for SDK,
not all files were included. A CL which attempts to use sdk.js (e.g.
https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2165757)
would then fail on several generated .d.ts issues.
Issues fixed:
- Usage of `Object` instead of `Map` causing issues with a type
alias of `string`, since TypeScript object notation only allows
primitives to be used as indices.
- Missing return types for function types
- A reference to `Protocol.NetworkAgent` which does not exist on
the protocol. Instead, that is part of the protocol-proxy-api.
Therefore, we must include the declaration file in the ts_library.
This also showed that the `ProtocolApi` needs to be exported
instead of declared.
This means that for any future reference to any Protocol type
that is actually an agent, we should be using the
`ProtocolProxyApi` definitions instead. To make sure Closure
understands that type, I aliased it in the externs.
R=jacktfranklin@chromium.org
CC=sigurds@chromium.org,szuend@chromium.org
DISABLE_THIRD_PARTY_CHECK=Typescript fixes
No-Presubmit: true
Bug: 1011811
Change-Id: I4f5a488edb2d5fa6c5ed12d33411efb5f7fb8133
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2165795
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@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>
Jack Franklin