The internal ninja copy action is, for Linux and Mac, the creation of a hardlink. In the case of an is_debug = false build, we copy the devtools_entrypoint file with ninja to the gen folder. However, should the file then change in the gen folder, those changes will be reflected back in the original source file since the two are hardlinked. This does happen when the JavaScript file moves to being managed by the TypeScript compiler, for example, because tsc often changes blank lines and adds sourcemap information to the file. If the gen folder is empty and no hardlink exists prior to build, there are no issues. If, on the other hand, the hardlink exists, and the TypeScript compiler runs, the file written in the gen folder will update, and then so will its original source. The ways to resolve this reflection back to the source folder is either by deleting the gen folder before rebuilding (where one anticipates changes being reflected in source), or, instead of using the ninja copy, using an action to call out to a script that will ensure that a new file is created and not hardlinked. This CL chooses the latter path. Change-Id: Id2cc8acdc240eb73ac736ddaf6f1eabdd08f8359 Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2308534 Commit-Queue: Paul Lewis <aerotwist@chromium.org> Reviewed-by: Jack Franklin <jacktfranklin@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.