mirror of
https://github.com/react/react-native-devtools-frontend.git
synced 2026-10-01 01:38:07 +08:00
Jack Franklin
b14dbe3426
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>
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.