// Conventions for importing code in Devtools to avoid build errors. Covers cross-module imports, internal imports, and the "import * as" requirement.
Migrating unit tests to foundation unit tests using TestUniverse and devtools_foundation_module. Use when moving tests away from DOM-heavy helpers like describeWithEnvironment or describeWithMockConnection.
MANDATORY: Activate this skill ANY TIME you need to build the project, run tests, or verify code health in DevTools. You MUST use this skill before executing commands like npm test, npm run build, autoninja, or linters, as it contains critical, repository-specific instructions on how to correctly format these commands, filter test runs, and interpret failures.
Use when managing branches, creating and uploading CLs, or handling stacked changes in the DevTools Gerrit-based workflow.
Workflow for merging a DevTools submodule into its parent module. Covers BUILD.gn consolidation and updating devtools_grd_files.gni.
Guidelines for building UI widgets using the MVP architecture in DevTools. Covers Widget lifecycle, lit-html views, and state management.
| name | devtools-imports |
| description | Conventions for importing code in Devtools to avoid build errors. Covers cross-module imports, internal imports, and the "import * as" requirement. |
This codebase follows a special convention for importing code that must be followed to avoid build errors.
In DevTools each folder of code is considered a module:
front_end/models/trace is the trace module.front_end/panels/timeline is the timeline module.Within each module there are multiple TypeScript files. The file that is named the same as the folder name is called the entrypoint.
front_end/models/trace/trace.ts is the trace module's entrypointfront_end/models/trace/ModelImpl.ts is part of the implementation of the trace module.When you want to reuse code from other modules, you must import that module via its entrypoint. Imagine we are in front_end/panels/timeline/TimelinePanel.ts. This import is GOOD:
import * as Trace from '../models/trace/trace.js'; // import the entrypoint
This import is BAD because we import a file that is NOT the entrypoint:
import * as ModelImpl from '../models/trace/ModelImpl.js' // NEVER ALLOWED
Additionally, you must import using the import * as syntax.
import {ModelImpl, X, Y} from '../models/trace/trace.js'; // BAD
import * as Trace from '../models/trace/trace.js'; // GOOD
If you are within the same module, it is OK to import from files directly rather than go via the entrypoint. You can also import specifically what you need.
For example, if you are editing front_end/models/trace/ModelImpl.ts this would be acceptable:
import {Foo} from './Foo.js'; // allowed because Foo.ts is in the same directory.