If you're in the front_end directory and you mistakenly include
front_end in an import, e.g:
import * as UI from '../../front_end/ui/ui.js';
instead of:
import * as UI from '../ui/ui.js';
It will cause problems in a release build. This CL lands an ESLint rule
to ban these, but still allows it for unit tests.
Fixed: 1157057
Change-Id: Ia49279794616568f9e88241152e3412fcd9a8b36
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2581547
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
On the bots these tests will run in out/Release but the component server
logic for figuring out the path to the gen directory was wrong; it
navigated up from its position into the root dir, and then back in to
`out/TARGET`. Rather than do that, we instead just walk up from the
scripts dir until we end up in the out/TARGET directory. That way
regardless of if we run in out/Default or out/Release, the script will
find the right directory.
Bug: 1153281
Change-Id: I1d369e47b9931ade60bc86ff52aea7105f10cefd
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2575086
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@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>
This CL introduces the infrastructure and first test for what we're calling
"Interaction tests". These are tests that can be used to test component
behaviour that cannot be tested via Karma unit tests but don't require an e2e
test either.
The best example here is complex user interactions: clicking and dragging a
mouse, or doing multiple tabs to navigate through the UI.
Note that the one interaction test added here for theme_colors isn't the best
example of a complex test, but it's a test that's good enough for now whilst we
get everything set up on infrastructure and make sure it runs without flaking.
Bug: 1153281
Change-Id: Ifb37639a557c459974f703b8954ae68a93d5d368
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2566808
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
As part of the work to enable Puppeteer component tests, we need to
configure the test suite to run either the hosted mode server or the
component docs server. This CL updates it to take a flag, and makes some
updates to the component docs server, which now has to run either
directly or in the out/Default/gen directory depending on how it is run.
I suspect I'll make a follow up CL to always run the component server in
out/Default/gen, but for now enabling it to detect its context is the
quickest way to unblock running it in tests. The next CL will add a
component test suite that can run a basic test against the component doc
server, but I have manually verified locally that I can run tests
against that server.
Bug: 1153281
Change-Id: I55bda4edd0a983d03bfecff0446b0f3e3a008b52
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2562707
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
To date the Karma singleRun option has been set based on whether the
developer sets the DEBUG environment variable. This CL adds support for
an additional REPEAT environment variable, such that someone can run
multiple, non-debug (i.e., headless) test runs.
In order to make this more convenient, this CL also improves the watcher
script (`npm run watch`) such that it restarts autoninja whenever files
are changed.
Therefore a developer can now run:
`REPEAT=1 npm run auto-unittest` and `npm run watch` in conjunction, and
have the code be recompiled automatically, and the unit tests
(re)started.
R=jacktfranklin@chromium.org
Change-Id: I8cff9eb7d223a5325e952413ddd5c1f55dd8aec2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2562709
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
This rule enforces that within a LitHtml template when we bind to the
`.data=` property we provide an explicit type cast that must be a type
reference.
This is one of the checks that the component bridges used to make, but
now we need to port them to ESLint rules.
Bug: 1130536
Change-Id: I401661289a829fd181bf91943fffe162b87de8b8
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2562345
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@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>
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>
Christy Chen