To make sure that a particular switch statement implements all
branches of, for example, a union or enum, we can implement the
`assertNever` function. This function will ensure in the type
system that the relevant branches are covered and will result
in compilation errors if a branch is missing.
This `assertNever` call is used together with a refactoring of
FormatterActions (which is a inlineable const enum) to ensure
that the tasks posted to the FormatterWorker stay in sync between
the formatter_worker and the FormatterWorkerPool. Since we can
not import the `formatter_worker` bundle in a non-worker context,
we instead extract it into a separate entrypoint, imported by both.
R=jacktfranklin@chromium.org
Bug: 1158395
Change-Id: Id643486936e7fad300d0f40774ee851adcc76ef5
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2589953
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Historically, cm_modes was used to lazily load CodeMirror MIME modes.
However, since we are no longer using CodeMirror MIME modes as
remote modules, we have switched to using ES imports to load them
instead. To that end, we made the `DefaultCodeMirrorMimeMode` extension
obsolete, as it became a noop for loading.
Moreover, cm_modes was loaded via the module.json infrastructure
present in the shell.json file. As such, in release mode these
files would properly load, but in a standalone (e.g. unit test)
environment, the missing links would cause these modes not to load.
To remedy the situation, we perform multiple fixes:
1. Remove the module.json extensions, since we are using ES imports
instead.
2. Remove DefaultCodeMirrorMimeMode.js (it is obsolete)
3. Move cm_modes.js into text_editor (this was the only module
that actually was loading the full version of CodeMirror)
4. Remove the infrastructure in CodeMirrorTextEditor.js to retrieve
the Mime modes (these were effectfully noops).
I have personally verified these Mime modes are still correctly
loading by opening a personal workspace with various Python/CC files
and confirmed that the syntax highlighting in the sources panel
is as expected.
R=aerotwist@chromium.org
Bug: 1127902
Change-Id: Ia3502713be247dc373e80fc3daa65ca7d9ecc1fe
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2577560
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
For our unit tests, we couldn't import the entrypoint of the
formatter_worker, since that entrypoint assumed it was running
in a worker context. Since our Karma unit tests run in a browser
context, it would start throwing errors on the postMessage call.
Instead, we should separate out the concerns of the formatter_worker
implementation and integration of its worker context with the
FormatterPool. To that end, we separate the implementation bundle
from the worker integration into a separate file "formatter_worker-entrypoint.ts".
To ensure we retain full test coverage, the integration part is
tested through e2e-tests, while the implementation of the
formatter_worker will remain being tested by unit tests.
After this change, we will now also compute full code coverage for
the formatter_worker folder, which we couldn't do before.
All of this will be used to port CSS pretty-printing tests from
layout to Karma tests, which will require yet another implementation
detail of the formatter_worker, which will now be exported through
its bundle entrypoint.
R=aerotwist@chromium.org
Bug: 1024752
Change-Id: I5f10a3ebab10e1012cf2244df779cdc31da06ed7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2575091
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Both front_end_devtools_module_entrypoint_sources and
generated_devtools_module_entrypoint_sources were unused, since
the `devtools_entrypoint` migration has finished.
Secondly, we can rename generated_typescript_entrypoint_sources to
generated_module_entrypoint_sources, since we no longer need to
distinguish between JavaScript and TypeScript entrypoints.
Lastly, we can clean up the definition of
devtools_module_entrypoint_sources to no longer include the
$resources_out_dir line, which saves some duplication.
R=aerotwist@chromium.org
Change-Id: I1a327cf40cec6630b3be7ac53e2c87f7e179c895
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2566802
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>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This CL updates the component docs server so it automatically injects the new
colour variables (which are part of the dark mode work) into the server. It
contains the following changes:
1. Pulling out the new colours into a new CSS file,
`ui/themeColors.css`, which contain all the new definitions.
2. Injecting that new file where we inject `inspectorStyles.css`
currently.
3. Updating the component docs server to intercept any requests to load
an HTML example file, read the HTML contents and inject a `<style>`
tag to load in the theme colours.
4. Additionally we now provide a small bit of JS that adds a handy
button to toggle light/dark mode without needing to dive into the dev
tools.
Fixed: 1152774
Change-Id: Ia2df0e00315dfeb532570ea5634fa54677337f76
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2560941
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
While js_profiler is an empty module, it has a single purpose:
specify a panel in its `module.json`. Therefore, it needs a corresponding
(unused) entrypoint file, with the appropriate GN infrastructure.
While the files itself are basically unused, the Runtime enforces
that every single module has a corresponding entrypoint. And that
assumption was invalid for `js_profiler`.
R=aerotwist@chromium.org
Fixed: 1151855
Change-Id: I14acce9c547c22c67a3b4bb26e8a7a2224015254
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2556689
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
The current bundling system with Rollup tries to determine when given a
file if it’s an entry point (e.g. ui/ui.js) or not (e.g ui/someFile.js).
If it’s not an entry point, it will bundle that file into the entry
point JS file. So when we go to bundle ui/ui.js, it’ll find files like
ui/someFile.js, and pull them into ui/ui.js, which ends up being a fully
“rolled up” version of the ui folder.
The problem comes when you nest these folders;
ui/components/components.js is an entry point but the logic that the
Rollup bundling code uses incorrectly detects it as a regular file. So
you end up with ui/ui.js including a rolled-up version of
ui/components/components.js, which itself is a rolled-up file. We then
ship ui/ui.js and ui/components/components.js, meaning we’ve shipped
components.js twice - once as a standalone file, and once because it was
rolled up into ui.js.
This CL fixes this by changing how we detect bundles, we now look for
importing files whose parent directory is the same, so:
- components/components.js is a bundle
- but components/foo.js is not a bundle
By making this change we also now correctly detect third_party bundles,
with the exception of Acorn which is a special case, so we can lose the
checks for that in our Rollup config.
The logic here is somewhat duplicated between Rollup's config and the
ESLint rule plugin that we have; I plan on making a follow-up CL that
tries to define this logic in one place so if it changes in the future
we can update the code in one place and have the linting & rollup
update, plus we'll be able to use the ESLint tests as coverage to ensure
we've not broken our bundling.
Fixed: 1144123
Change-Id: Idd82a3ef69a09871867626a0d74266e25801243f
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2534202
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Since issues is now TypeScript-authored and is the only module
that was relying on Marked, we are no longer bound by marked
being in a direct subdirectory of front_end. Therefore, we
can treat it as lit-html and directly import from
third_party/marked instead.
To make sure that we don't bundle Marked in issues itself,
we have to update the Rollup logic to exclude it for now.
We will clean that up in a future Cl, where we are changing
the heuristic for "bundliness".
R=szuend@chromium.org,jacktfranklin@chromium.org
Bug: 1011811
Change-Id: Ieb40470a9efcd072ff5b360b7bd487f15df2a689
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2529157
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This CL introduces the new DataGrid component, and is split into two:
- DataGrid, which is a "plain" component that takes data and renders it.
- DataGridController, which is a "smart" component that can take the
data and manipulate it (e.g. sorting), before passing it into a DataGrid
to be rendered.
These components are not feature complete in that they do not support
all features of the incumbent `DataGrid.js` but they are not designed
to. The goal here is to land the initial data-grid components, and then
work on using them in DevTools (as part of the protocol monitor). At
that point we can extend functionality by seeing what is missing and
testing in DevTools, rather than testing in isolation.
This CL includes the implementation, unit tests and component
documentation examples of the functionality that does exist, along with
a README explaining the two components and when to use each one.
Bug: 1125966
Change-Id: I1b5c9a0174c4563be64b5b4adcc8251d1498b55d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2461772
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Andres Olivares <andoli@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
There previously were two special files that were handled
by `build_release_applications`: root.js and RuntimeInstantiator.js.
Both files are explicitly part of the startup process of DevTools
and its various entrypoints.
To remove the copying from `build_release_applications`, we have
to move these to the relevant `devtools_entrypoint`. Since a
`devtools_entrypoints` bundles all subdirectories, we can't keep
these files in `front_end/` directly. Instead, we move these files
to `startup/` to denote their special-casing in the startup process.
Next to that, we have to fix all usages of these files in the entrypoints.
For all JavaScript entrypoint files, all side-effect legacy files
that are loaded by `startup.js` (previously known as `root.js` and renamed
to prevent confusion with the `root/` module) are removed. All
"additional" legacy files that a particular entrypoint requires are
still loaded as-is.
The RuntimeInstantiator is moved to become an implementation detail
of `startup/`. Therefore, all of the usages that were previously
importing from `RuntimeInstantiator` now import via `startup.js`.
In the end, the special-casing of these files are removed and renamed
for clarity. In the future, we want to remove the complicated
entrypoints startup process, but we are not ready for that yet.
That will require additional cleanups with `resources` in `module.json`
before that change can happen.
R=aerotwist@chromium.org
Bug: 1131500
Change-Id: I198d5a62d2aab70f842c68d9b4c0871fde1587a4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2485072
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
To continue to move away from `build_release_applications.py`, move
building `common-legacy.js` into `devtools_entrypoint`. In the end,
it will allow us to remove `_rollup_module` from
`build_release_applications.py`.
The logic in `build_release_applications.py` is updated to assume
a pregenerated `-legacy.js` file based on the `pre_generates_legacy`
option in the `module.json` file. Once all `-legacy.js are migrated,
we can remove this option once again.
To make sure that we Rollup properly, we should assume that an
entrypoint in the same folder is regarded as external. Otherwise,
we would rollup the contents of `common.js` into `common-legacy.js`,
which is not what we want.
R=aerotwist@chromium.org
Bug: 1131500
Change-Id: Idcda3e1c2436a0bebb36501523c8d586d6e86fac
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2450297
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This reverts commit 862107080d.
Reason for revert: Chromium build issue fixed.
Original change's description:
> Revert "Reland "Remove support for remote modules""
>
> This reverts commit b3859e8d65.
>
> Reason for revert: Breaking roll (https://ci.chromium.org/p/chromium/builders/ci/win-archive-rel/17700)
>
> Original change's description:
> > Reland "Remove support for remote modules"
> >
> > This reverts commit d5044ddf05.
> >
> > Reason for revert: Fixed Chromium debug issue.
> >
> > Original change's description:
> > > Revert "Remove support for remote modules"
> > >
> > > This reverts commit 419c91eff6.
> > >
> > > Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
> > >
> > > Original change's description:
> > > > Remove support for remote modules
> > > >
> > > > LightHouse is currently broken in Canary, because of problems with
> > > > the appspot server. This isn't the first occurrence of this problem
> > > > and it becomes increasingly more difficult to figure out why the
> > > > server keeps on breaking. This is combined with a large infrastructure
> > > > cost of supporting remote modules and a confusing debugging experience
> > > > when working with it locally.
> > > >
> > > > The reason we had remote modules was the fact that these modules are
> > > > too large to be included in the Chromium bundle. In the last months,
> > > > we have made numerous remote modules bundled, by applying minifications
> > > > and optimizations to each module.
> > > >
> > > > The remaining remote module that we are currently shipping is LightHouse.
> > > > Since the remote appspot server is broken and unlikely to be fixed
> > > > anytime soon, now is the best time to finally resolve the remote
> > > > modules question.
> > > >
> > > > Therefore, we remove support for remote modules from the `module.json`
> > > > files and `Runtime.js`. Additionally, we update the build system
> > > > to properly generate the required files and load them via ES modules.
> > > >
> > > > We will be able to perform subsequent cleanups in the Runtime to remove
> > > > more infrastructure related to scripts/remote modules, but given that
> > > > this CL is already quite large we are doing that in a follow-up CL.
> > > >
> > > > Follow-up action items for the LightHouse folks are to further decrease
> > > > the bundle size for LightHouse. Since we are now loading it via ES
> > > > modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> > > > well. This allows us to remove the copy of the SDK files, as well as
> > > > make use of proper ES exports, rather than the browserified requires.
> > > >
> > > > R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
> > > >
> > > > Fixed: 1128890
> > > > Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> > > > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > > > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> > >
> > > TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
> > >
> > > Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
> > > No-Presubmit: true
> > > No-Tree-Checks: true
> > > No-Try: true
> > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
> > > Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
> > > Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
> >
> > Change-Id: I26bf0565297c8e167039362b30109d7020bbca56
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418431
> > Commit-Queue: Paul Lewis <aerotwist@chromium.org>
> > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
>
> TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org,alexrudenko@chromium.org
>
> Change-Id: I0ed24d32c9b68bc4cb8026f6fc362540800beeb0
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418408
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Change-Id: I8718e9d94c384a13fd18261f8f497d32418658fb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2421690
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This reverts commit b3859e8d65.
Reason for revert: Breaking roll (https://ci.chromium.org/p/chromium/builders/ci/win-archive-rel/17700)
Original change's description:
> Reland "Remove support for remote modules"
>
> This reverts commit d5044ddf05.
>
> Reason for revert: Fixed Chromium debug issue.
>
> Original change's description:
> > Revert "Remove support for remote modules"
> >
> > This reverts commit 419c91eff6.
> >
> > Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
> >
> > Original change's description:
> > > Remove support for remote modules
> > >
> > > LightHouse is currently broken in Canary, because of problems with
> > > the appspot server. This isn't the first occurrence of this problem
> > > and it becomes increasingly more difficult to figure out why the
> > > server keeps on breaking. This is combined with a large infrastructure
> > > cost of supporting remote modules and a confusing debugging experience
> > > when working with it locally.
> > >
> > > The reason we had remote modules was the fact that these modules are
> > > too large to be included in the Chromium bundle. In the last months,
> > > we have made numerous remote modules bundled, by applying minifications
> > > and optimizations to each module.
> > >
> > > The remaining remote module that we are currently shipping is LightHouse.
> > > Since the remote appspot server is broken and unlikely to be fixed
> > > anytime soon, now is the best time to finally resolve the remote
> > > modules question.
> > >
> > > Therefore, we remove support for remote modules from the `module.json`
> > > files and `Runtime.js`. Additionally, we update the build system
> > > to properly generate the required files and load them via ES modules.
> > >
> > > We will be able to perform subsequent cleanups in the Runtime to remove
> > > more infrastructure related to scripts/remote modules, but given that
> > > this CL is already quite large we are doing that in a follow-up CL.
> > >
> > > Follow-up action items for the LightHouse folks are to further decrease
> > > the bundle size for LightHouse. Since we are now loading it via ES
> > > modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> > > well. This allows us to remove the copy of the SDK files, as well as
> > > make use of proper ES exports, rather than the browserified requires.
> > >
> > > R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
> > >
> > > Fixed: 1128890
> > > Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> > > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> >
> > TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
> >
> > Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
> > Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
> > Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
>
> Change-Id: I26bf0565297c8e167039362b30109d7020bbca56
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418431
> Commit-Queue: Paul Lewis <aerotwist@chromium.org>
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org,alexrudenko@chromium.org
Change-Id: I0ed24d32c9b68bc4cb8026f6fc362540800beeb0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418408
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Andres Olivares