The previous attempt of this fix was in https://crrev.com/c/2687497
That CL was reverted, as it inadvertently added more files to the
runtime_deps then was intended. Most notably, it erroneously included
`tsconfig.json`, `tsbuildinfo` and `d.ts` files.
Instead, we should manually filter out only those files that we are
interested in. In this case, these are the `js` and `js.map` files.
Once these are added to the runtime_deps, the layout tests can access
them, as they are pushed to the bots.
I have verified that the following command shows the expected output:
gn desc out/Default front_end/platform:bundle runtime_deps
R=jacktfranklin@chromium.org
Bug: 1174013
Change-Id: I6bc25665f06b5968bbd9748696a5723edac84ddc
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2697201
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>
All relevant build output files are now put into gen/front_end.
To make sure that we don't run into duplicate JS entrypoint
files, we have to turn of the emit of these targets in
front_end/BUILD.gn, such that build_release_applications can
put its output there. Since build_release_applications takes
the files from the front_end source directory, not the gen
directory, this causes no issues.
After this change, it is possible to use --custom-devtools-frontend
with gen/front_end rather than resources/inspector.
DISABLE_THIRD_PARTY_CHECK=Update TypeScript noemit
R=aerotwist@chromium.org
Bug: 1174013
Change-Id: Iad331ff0a28871a0ec297483fa03fbb485d05fb4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2672031
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This is a reland of 159d86d3fb
The reland fixes the setting of "use_rbe" on the ts_library template
iff RBE is enabled for devtools directly. This prevents an
"unused variable" error when building with "use_rbe=true" and
"devtools_use_rbe=false".
Original change's description:
> Support RBE for building TypeScript int DevTools
>
> This CL implements initial support for executing TSC in the cloud by:
> 1) Introducing a new GN arg "devtools_use_rbe". This is experimental
> and will be folded into the Chromium "use_rbe" flag once RBE
> building has stabalized.
> 2) Pass the configured Chromium rewrapper along to ts_library.py.
> 3) Add a new function "runTscRemote" that calculates inputs required
> and invokes rewrapper
>
> Support is currently very limited:
> - Only works with a full Chromium checkout (NOT standalone DevTools)
> - Only works on leaf modules (modules without DEPS)
>
> Modules that can't be currently built in the Cloud are built locally
> as per usual.
>
> DISABLE_THIRD_PARTY_CHECK=Change typescript.gni
>
> R=tvanderlippe@chromium.org
>
> Bug: chromium:1139220
> Change-Id: Id7a1e6c113466414f6daaa661456d8debfe6696d
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2652508
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
DISABLE_THIRD_PARTY_CHECK=Change typescript.gni
Bug: chromium:1139220
Change-Id: I536fb580c3814a82525344ab5ebd5fb853568387
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2659015
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
This reverts commit 159d86d3fb.
Reason for revert:
This has broken a few re-client builders in Chromium:
* https://ci.chromium.org/p/chromium/builders/ci/Linux%20Builder%20%28reclient%29?limit=200
* https://ci.chromium.org/p/chromium/builders/ci/Linux%20Builder%20%28reclient%29
```
$ gn gen out/rbe-demo --args='use_rbe=true is_debug=false'
ERROR at //third_party/devtools-frontend/src/scripts/build/ninja/devtools_entrypoint.gni:132:19: Assignment had no effect.
use_rbe = false
^----
You set the variable "use_rbe" here and it was unused before it went
out of scope.
See //third_party/devtools-frontend/src/front_end/common/BUILD.gn:47:1: whence it was called.
```
Original change's description:
> Support RBE for building TypeScript int DevTools
>
> This CL implements initial support for executing TSC in the cloud by:
> 1) Introducing a new GN arg "devtools_use_rbe". This is experimental
> and will be folded into the Chromium "use_rbe" flag once RBE
> building has stabalized.
> 2) Pass the configured Chromium rewrapper along to ts_library.py.
> 3) Add a new function "runTscRemote" that calculates inputs required
> and invokes rewrapper
>
> Support is currently very limited:
> - Only works with a full Chromium checkout (NOT standalone DevTools)
> - Only works on leaf modules (modules without DEPS)
>
> Modules that can't be currently built in the Cloud are built locally
> as per usual.
>
> DISABLE_THIRD_PARTY_CHECK=Change typescript.gni
>
> R=tvanderlippe@chromium.org
>
> Bug: chromium:1139220
> Change-Id: Id7a1e6c113466414f6daaa661456d8debfe6696d
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2652508
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
TBR=szuend@chromium.org,tvanderlippe@chromium.org
Change-Id: Ie82249ab143f86bc61d706759b7b72c43ba4c53f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1139220
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2658258
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@google.com>
Reviewed-by: Takuto Ikuta <tikuta@chromium.org>
Commit-Queue: Ye Kuang <yekuang@google.com>
This CL implements initial support for executing TSC in the cloud by:
1) Introducing a new GN arg "devtools_use_rbe". This is experimental
and will be folded into the Chromium "use_rbe" flag once RBE
building has stabalized.
2) Pass the configured Chromium rewrapper along to ts_library.py.
3) Add a new function "runTscRemote" that calculates inputs required
and invokes rewrapper
Support is currently very limited:
- Only works with a full Chromium checkout (NOT standalone DevTools)
- Only works on leaf modules (modules without DEPS)
Modules that can't be currently built in the Cloud are built locally
as per usual.
DISABLE_THIRD_PARTY_CHECK=Change typescript.gni
R=tvanderlippe@chromium.org
Bug: chromium:1139220
Change-Id: Id7a1e6c113466414f6daaa661456d8debfe6696d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2652508
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
GRD compression takes a while. It takes a particularly long while in
debug builds. This change skips compression on debug builds which
takes the GRD step from ~55 seconds to ~5 seconds.
Alternately we could use this framework (passing through the debug state
of the build) to try different compression options as suggested in the
bug.
Test results for debug-component and release builds with this change:
5.2 weighted s to build gen/content/browser/devtools/devtools_resources_grit.d.stamp, gen... (5.2 s elapsed time)
24.5 weighted s to build gen/content/browser/devtools/devtools_resources_grit.d.stamp, gen... (24.5 s elapsed time)
Release is unchanged but debug is ~11 times faster.
Bug: 1162467
Change-Id: I017ec872a1645fef55aff09472cdf4427146d17b
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2639276
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
depot_tools ships a "vpython" binary that is added to the $PATH
for all Chromium engineers. This binary is versioned by depot_tools
which we roll in ourselves as part of `gclient sync`.
By using `vpython` instead of `python`, we are no longer depended
on the Python version installed locally and instead use the version
we pull in from DEPS.
R=liviurau@chromium.org
Change-Id: If49a54c24b6cf129ff843cd9ca1140a723a78afb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2571462
Reviewed-by: Liviu Rau <liviurau@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>
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>
For all `_module.js` files, we currently copy all `modules` into
the `module.json` metadata. However, since then the Runtime got
updated to always load the entrypoint. This is possible, because
in release modes only the entrypoint exists and all other files
are removed.
Therefore, we can use an empty array to denote that solely the
entrypoint should be loaded by the Runtime. If however the module
has a legacy file, the Runtime needs to load that instead. (See
`Runtime._loadModules` for more information) Therefore, include
solely the legacy file to the metadata information in the
`_module.js` to load it.
Eventually, this will allow us to remove the files from the modules
array in the `module.json`, as only Closure would require that
information.
R=aerotwist@chromium.org
Bug: 1131500
Change-Id: Ie14bd55b29b356a39aad7e8ca2041c979bd1b2cb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2461783
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
This CL addresses a few issues that will help make it possible
to build Chromium using Python 3.
Nothing in this CL should cause any functional changes, and
Python 3 is not required (indeed, won't even work yet), but
this CL will be needed to unblock other work.
See https://crrev.com/c/2333868 for the roll-up Chromium patch,
which also has multiple other dependencies.
Bug: 1112471
Change-Id: Ica8a5b2b24674e1abd267bcd558b7101a6da6fc5
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2330718
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@google.com>
Since formatter_worker.ts is the actual entrypoint for the worker,
we should perform the message handling and postMessage invocations
there. This allows us to remove accesses to the `self.postMessage`
global in the implementation of the parsers and formatters, allowing
proper unit testing. Note all `self.postMessage`s have been removed,
as that requires additional refactoring in a follow-up CL.
This also paves the way for removing `formatter_worker_entrypoint`,
which is currently a no-op file. That requires additional infrastructure
changes to `Common.Worker` to allow specify a subfolder of `front_end/`
to be passed as the entrypoint.
Note that this CL also removes the `parseSCSS` method, which appears to
be unused in both the Chromium codebase as well as externally. Testing
on stable shows that we are currently not formatting `.scss` files
anyways.
R=aerotwist@chromium.org
Bug: 1011811
Change-Id: I808c5ea83efa5ec9fed6bd1aec2418487f553848
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2410232
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@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>
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>
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>
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>
This refactors away the cachedResources from an object map
to a normal Map as defined in `Runtime.js`. The Map is used during
boot time by setting the relevant stylesheet contents, which is
included by `build_release_applications`. Moreover, it moves the
`*_module.js` files into the `modules` array rather than scripts.
This ensures that `*_module.js` files can use ES imports.
In a follow-up CL, we can do additional cleanup in the Runtime
to stop retrieving `resources` in `_loadResources`, as that should
no longer be possible. (In both debug and non-debug we build the
appropriate `_module.js` files)
R=aerotwist@chromium.org,aerotwist@chromium.org
Bug: 1058320
Change-Id: I89602b332360338f5914038f6cd505f75b531f8e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2398829
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
While we implemented this check for `devtools_module` and
`devtools_entrypoint`, we did not do so for `devtools_pre_built`.
This caused build failures yesterday when we forgot to add the
live directive of lit-html in the GRD files.
Therefore, implement the same check for `devtools_pre_built`. This
not only catches the live directive file missing, but also found out
that the imports for Acorn were using the wrong version. We use the
`.mjs` bundles from Acorn, not the `.js` versions.
R=jacktfranklin@chromium.org,aerotwist@chromium.org
Bug: 1126630
Change-Id: I54004efda6fb0ac50f894262f09fe2104d1b2f86
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2403322
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
When TypeScript writes to pre-existing files, it will overwrite the
contents, but it won't create a new file per se. If files in gen/ were
previously created by devtools_pre_built they will be hardlinked to the
original source file, thus any changes tsc makes to the file in gen will
be reflected back to the source. This causes an issue with ninja, since
it believes on the next run that the source file has changed.
This CL updates the behavior of devtools_pre_built such that it no
longer calls gn's copy, but rather a node utility that ensures that
there is a freshly minted copy of the file rather than a hardlink.
Change-Id: I11a23fce764101eb237e434a64159223ef8d700e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2335277
Auto-Submit: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Tim van der Lippe