mirror of
https://github.com/react/react-native-devtools-frontend.git
synced 2026-10-14 10:34:48 +08:00
Tim van der Lippe
f5feb1fec6
This reverts commit862107080d. Reason for revert: Chromium build issue fixed. Original change's description: > Revert "Reland "Remove support for remote modules"" > > This reverts commitb3859e8d65. > > 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 commitd5044ddf05. > > > > Reason for revert: Fixed Chromium debug issue. > > > > Original change's description: > > > Revert "Remove support for remote modules" > > > > > > This reverts commit419c91eff6. > > > > > > 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>
DevTools Scripts
Development workflow scripts
These are scripts that can be useful to run independently as you're working on Chrome DevTools front-end.
The newer scripts such as for testing and hosted mode are written in Node.js, which has become the standard toolchain for web apps. The older scripts such as building (e.g. bundling and minifying) are written in Python, which has first-class support in Chromium's infrastructure.
Overview
Folders
- build - Python package for generating DevTools debug and release mode
- chrome_debug_launcher - automagically finds Chrome Canary and launches it with debugging flags (e.g. remote debugging port)
- closure - see section on Closure Compiler below
- gulp - experimental build process written in node.js & gulp to remove the dependency on Chromium-specific build tools (i.e. gn and ninja)
- hosted_mode - run DevTools on a localhost development server
- jsdoc_validator - enforces the use of Closure type annotations
Python Scripts
- compile_frontend.py - runs closure compiler to do static type analysis
- Note: the compiled outputs are not actually used to run DevTools
- lint_javascript.py - run eslint
- optimize_svg_images.py - manually run when changing svg images
Node.js scripts
The easiest way to run the node.js scripts is to use npm run which displays all the commands. For more information on the specific npm run commands, take a look at the primary devtools front-end readme (../readme.md).
Closure
DevTools manually rolls the closure compiler to ./closure. If you manually roll closure compiler, you will need to re-generate the closure_runner (in ./closure) and jsdoc_validator custom jars using the python scripts in their respective directory.