Add overrides for the default background colors of some the Material components currently in use by Devtools. Most likely a regression by a recent Material version bump.
PR Close#61969
This makes a few changes to try to smooth over the process:
1. Updates changelog commands to filter out `refactor` commits.
2. Tweaks the changelog command to generate a markdown list for easy copy-pasting.
3. Links directly to the store pages to cut down on clicks.
4. Moves the source code section a bove the reviewer note and changelog, to match the ordering of the Firefox Add Ons form.
PR Close#61883
This commit migrates the remaining pieces of `compiler-cli` to
`ts_project`. This involves a few more things during migration:
- the `ng_module` ngc_wrapped rule broke as part of this change, so we
switched it to `ts_project` too. This logic is soon gone anyway.
- we needed an extra pnpm "package.json" for the linker babel test. This test is
loading from the real compiler-cli npm package. Babel needs a real
node module for this, so this solution seems reasonable. It may be
worth exploring in the future to move this test into an integration
test though.
- the older integrationtest in compiler-cli is removed as the coverage
is much better with the compliance test suite and this test.
PR Close#61826
Commit 3e70d64 introduced cdk version 20.0.0-rc2 which introduced a change to how the cdk virtual scroll sets some internal state.
Previously in DevTools we were using a computed incorrectly to respond to changes in the directive forest and apply them to the underlying datasource. With the change to the CDK shown above, this incorrect usage caused us to attempt to update underlying signals in the virtual scroll directive while within a computed callback, throwing an error.
This commit corrects our usage by swapping from a computed to an effect, allowing the underlying signals in the scroll directive to be updated without error.
PR Close#61812
On clicking a route in the router tree, the route details panel is displayed.
- The panel shows the details of the selected route, including the path, component, providers, guards etc.
- Clicking on a chip will navigate to the corresponding source file in the editor.
- Clicking on the path will navigate to the corresponding route in the router tree.
Demo Application Source: https://github.com/sumitarora/angular-routes-demo
Demo Application Deployed: https://sumitarora.github.io/angular-routes-demo/#/
PR Close#59999
The release process overview is out of date and does not accurately reflect section headers. It's not worth the maintenance effort of keeping it in sync with the rest of the doc.
Added a step 0 to check if there's actually anything to release, reusing the command from later in the doc.
Also makes a few random small corrections to reflect the new release process.
PR Close#60892
This commit adds the support for defer block in the Angular DevTools.
@defer block are now visible in the directive tree and give access to defer & hydration details.
This feature also brings support of incrementation hydration.
PR Close#60629
- Highlight only the matched part of the text
- Select the first match by default
- Show the matches count along with the currently selected one
- Minor UI fixes and performance optimizations
PR Close#60672
`ng.getDirectiveMetadata` receives the component instance, not the raw DOM element.
This assumes that `ng.getComponent` is implemented in all environments and that the root element itself is a component.
PR Close#60991
This moves the commit step to the start of the process and releases after merging it. This has two key benefits:
1. The commit history now reflects the actual release (ex. any DevTools commits before the release commit are actually included in that release). Previously the changes in a release were dictated by the release PR branch, which is an ephemeral target. Other PRs may be merged to `main` before the release PR, and those changes would not be included in that DevTools release.
2. We can now compute a changelog based on this more accurate history.
The downside to this change is that release PRs are now blocking releases in a way they weren't before (which is likely desirable in the grand scheme of things), meaning we need to be more diligent about merging them in a timely manner.
I added a short script for listing DevTools commits since the last release, taking advantage of the more accurate commit history. This should make changelog generation a lot easier, even if there's still a manual process of rewriting the commit message into a line item in release notes.
Also made a few minor cleanup changes such as escaping the markdown in the suggested reviewer note so it can be more easily copy-pasted from the rendered format of this doc.
PR Close#60646
Currently, highlighting works only when a directive explorer node is hovered. The change enables this feature on node selection as well.
PR Close#60744
This is a follow-up to the recent devtools linking change, leveraging
the dedicated package that we are also using in the components
repository; avoiding future duplication.
The latest version of that package contains a fix for an issue where
the linked bundles did not rewrite imports to shared chunks.
Such imports need to also point to their linked variants.
PR Close#60822
Previously the `frameUrl` option in `chrome.devtools.inspectedWindow.eval` would throw errors when used in Firefox, preventing inspect source functionality for firefox users even if they don't need to target a particular frame on the page (they are on the top level frame with Angular DevTools).
Now this behaviour is as follows:
Firefox user that has the top level frame selected -> DevTools inspect functionality works as expected.
Firefox user that has a non-top level frame selected -> DevTools now renders a snackbar message informing the user of the limitation.
PR Close#60430
This updates the DevTools protocol to send Wiz/ACX metadata in addition to Angular metadata. Fortunately we don't need to worry about backwards compatibility here (`framework` is required for example), but the design roughly mirrors `DirectiveDebugMetadata` in `@angular/core`.
Beyond that, this is mostly plumbing through an extra data slice in the form of `props` provided by Wiz. An earlier version implemented `events` as their own slice as well, but was removed as there is currently no generic way to disambiguate events from any other form of callback passed in as a prop. Instead, event callbacks are visualized as functions under the "Props" category.
Working with `DirectiveMetadata` as a union is unfortunately a bit annoying since it requires casting to more specific `{Angular,Acx,Wiz}DirectiveMetadata` types for TS to allow property access, even when the properties are optional anyways.
This commit is mostly for adding Wiz, but does add a bit of ACX functionality which is not fully tested.
PR Close#60475
This type was incorrect, as only components have `encapsulation` and `onPush` values. `ng.getDirectiveMetadata` does not return these properties for directive inputs.
Unfortunately the `| Partial<AngularComponentDebugMetadata>` is necessary to reference these properties or else TypeScript will reject their usage.
PR Close#60475
This allows `ng.getDirectiveMetadata` to be implemented by Wiz and ACX with subtly different shapes to match the nuances of those frameworks.
Existing usage of `{Component,Directive}DebugMetadata` was moved over to `Angular{Component,Directive}DebugMetadata` as appropriate, since the implementation of `ng` in `@angular/core` is specific to Angular. Only the types support Wiz and ACX.
I opted to merge `ComponentDebugMetadata` and `DirectiveDebugMetadata` into a single type of all the frameworks including both components and directives (recall that components extend directives). The reasoning for this is because Wiz does not support directives (you can kind of think of "Wiz Directive" as an abstract class extended by "Wiz Components"). I felt that a `DirectiveDebugMetadata` containing only Angular and ACX types would be a bit of a trap and lead to bugs when used. It's safer to just have the single type containing all the possible results from `ng.getDirectiveMetadata`.
I also chose to leave the `ng` type as is internally, since `@angular/core` implements a specific concrete version of it narrowed to Angular types. Separately I defined an expanded `FrameworkAgnosticGlobalUtils` which redefines `ng.getDirectiveMetadata` to include Wiz and ACX. We want this type to exist in the Angular GitHub repo so it can be referenced as a common primitive across all three frameworks. This is sufficient for now, however longer term we will likely want to actually manually define the function types in this framework-agnostic interface and make Angular's version properly implement it rather than extend and overwrite Angular's type.
PR Close#60475
Extract all colors from the stylesheets, reduce their number by merging the similar ones and organize them into themes represented by CSS variables.
PR Close#60374
This commit fixes the linking of CDK/Material which recently broke
because the CDK/Material package now comes with potential shared FESM
chunks; that our current hard-coded, manual linking process doesn't know
about. This ultimately resulted in duplicate code, breaking
Material/CDK.
This commit fixes that.
In addition to the fix, we simplify our linking significantly and reduce
the rather large complexity around linking, or having to specify every
entry-point manually, by linking the full package and putting it into
a different location. This is also what we conceptually are doing in
Angular Material as part of the `rules_js` migration.
PR Close#60516
Angular DevTools now supports mutating objects underneath signals in the property explorer view.
This is done by performing an "immutable update" by recursively copying objects underneath a signal and overwriting the one property specified. For example, if the user attempted to set `foo.bar.baz[2].hello = 'world'` and `bar` was a signal, this would effectively become:
```typescript
foo.bar.set({
...foo.bar(),
baz: [
...foo.bar().baz.slice(0, 2),
{
...foo.bar().baz[2],
hello: 'world',
},
...foo.bar().baz.slice(3),
],
})
```
The motivation for immutable updates is because signals and Angular change detection don't really like interior mutability of signal values. If we didn't do this, any kind of comparison or dirty check would prevent the UI from updating. If an application attempts to change a deeply nested property inside a signal, it doesn't work today. DevTools should generally be limited to operations an application could do itself, and the recommended approach to make such a change like this is an immutable update. Creating entirely new objects intentionally breaks referential equality such that the application can properly react to the change.
Unfortunately, it is not possible to make immutable updates in a truly generic sense. You can't just copy a class for instance `({...new MyFoo()}).doSomething()`. We could do something fancier like manually copying over the prototype or something like that, but there is no way to do this without breaking class semantics (ex. the class might reasonably rely on the constructor being called). Therefore we instead reject any mutations to non-primitive objects. In the future, we might expand the set of "primitives" to include other built-ins and well-known objects like `URL` or `Element`, but those are out of scope for now.
I opted to ban mutating the result of a readonly/computed signal. While the mutation is likely to succeed, a subsequent rerun of the `computed` will immediately drop the change. However, I opted to allow mutating the result of a getter property. This has a similar problem because it might be returning a synthetic object which will be invalidated on the next execution, but it is possible and reasonable for a getter to return the same object multiple times such that a mutation may reasonably survive other updates. DevTools can't easily know whether a getter actually will return the same object on each execution or not, so we optimistically assume the reference is stable. If it isn't, the mutation will be lost whenever the getter is re-executed.
PR Close#60381
Sometimes `forest` can be empty if the provided roots are empty, and was leading to a "Cannot read `resolutionPath` of `undefined`" error. Now we check the forest has a tree in it before looking up `resolutionPath`.
There might be a separate issue with the fact that the backend script likely shouldn't be emitting an empty forest in the first place. However we already check that a resolution path exists at all, so I think it's fair to also check that a tree was provided. We can separately look into making sure the backend is emitting valid data.
PR Close#60403
See associated pull request for more information.
Closes#59956 as a pr takeover, `@angular/build-tooling` has been rolled back as due to missing `@aspect_rules_js`.
PR Close#60387
The main goal of this change is to remove `categoryOrder` which effectively hard-codes the supported length of `panels`. Adding another item to `panels` is not rendered unless that is added to `categoryOrder`.
My solution to this is to make the set of categories a signal, with each category able to produce the data inside it. This allow `CdkDragDrop` to rearrange categories but then still produce the correct data in the template without needing a separate array to track order.
Also removed `hidden` and inlined it in the template, since the logic was the same for every panel.
`moveItemInArray` is unfortunately an in-place move, so I needed to manually clone the array to ensure `panels` observes an immutable update which works better with signals and change detection.
PR Close#60286
These links aren't that helpful in the context of Angular DevTools for a few reasons:
1. Users of the extension should already have a general understanding of core Angular concepts, inputs and outputs included.
2. The input and output links go to API documentation which isn't useful for someone who doesn't actually understand the core concepts anyways.
3. These links point to signals documentation even though DevTools shows non-signal inputs and outputs.
4. Properties linked to template binding docs, which doesn't *really* have anything to do with the plain JS properties being shown in DevTools anyways.
PR Close#60284
Previously, if `ng.getDirectives` was not implemented, Angular DevTools won't throw when attempting to load the component tree. Now it safely ignores the function and assumes no directives exist on the page.
PR Close#60209
In general, we can't assume all applications implement the full `ng` contract as many are older Angular application which pre-date the current interface. As a result, it is safer to type this as a `Partial`.
For now, I just added non-null assertions at all current usage locations, as we do generally feature detect before using these fields. However, hopefully this `Partial` type will make it harder to accidentally call a function which might not be supported.
PR Close#60209
Previously Angular DevTools would throw when run on an application which does not support `getInjector`, now it safely ignores it and assumes dependency injection is not supported.
PR Close#60206
Previously this was throwing errors in applications with no Router token.
Now it skips emitting events for the router tree when it is unable to find the Router token.
Note: If these events don't emit, DevTools treats the RouterTree feature as disabled.
PR Close#60221
Previously Angular DevTools would throw if `ng.applyChanges` was not defined. Now DevTools silently ignores the issue, assuming `mutateComponentOrDirective` was sufficient to update the application.
PR Close#60207
Previously, the profiler would only emit the specific template event and context when a template is created/updated, but not the template function related to the event.
This commit emits this function by using the third argument of the profiler function, which previously was only used for lifecycle hooks and output listeners. This commit also renames this arg to eventFn to express that it varies depending on the event type emitting from the profiler.
Note: this change is fully backwards compatible, since previously these template events did not use the third arg of the profiler function.
PR Close#60174
- The token rendered in the first col of the table is now being truncated in favor of the horizontal scroll of the panel which should make the log button accessible/visible all the time
- Introduced a "No such providers" label when a filter is applied
- The icon of the logProvider button has been substituted with `code` (as per the doc)
- The font size and width of the provider type filter have been slightly improved
PR Close#59531
The purpose of this component is purely to encapsulate and offload the styles from `devtools.component.scss` since it wasn't very clear what their scope is.
PR Close#59916
Use the new UI and drop the `InjectorTreeVisualizer` dependency. Additionally, use concrete values for `SerializedInjector.type` type instead of `string`.
PR Close#60011
`-x dist/` never worked for reasons I don't really understand. Historically I've just deleted `dist/` before zipping. I tried a few different approaches, but all of them lead to some form of "Name not matched" error in `zip` of the `dist/` directory. Instead I just opted to delete `dist/` as part of the zipping command.
The link to recent DevTools commits seems good enough to manually write a changelog. All relevant commits should be using `refactor(devtools)`, so the string "devtools" should definitely be in there.
PR Close#59792
- Move all styles to ng-devtools/src/styles.
- Create a BrowserService that detects the browsers and adds it as a class to the body. Move global browser styles.
- Create theme mixins that incorporate the browser type into them.
- Refactor some of the affected code along with the introduced changes.
PR Close#59589
This commit solves two cases
Bug: When a directive of the same name is selected, the property view tab would not update properly. This was caused by a signals refactor that changed the behaviour of a string input property to not re-render because the underlying signal did not change (string equality). This is fixed by converting this input into an object.
Bug: When a selected element is removed from the component tree, DevTools would not rerender the component tree properly and deselect that component. Now if DevTools detects that a component is removed, it re-renders the tree and deselects the component.
PR Close#59873
Several profiler calls don't have any meaningful instance when
producing a profiling event. This commit changes the default
instance value to null to sreamline profiler invocations.
PR Close#59233
It looks like this height property was redundant prior to upgrading to angular/material 19.1.0-rc.0. An interaction between this property and that update caused elements inside of material expansion panels to be hidden.
This PR removes this unnecessary height assignment entirely.
PR Close#59493
Several profiler calls don't have any meaningful instance when
producing a profiling event. This commit changes the default
instance value to null to sreamline profiler invocations.
PR Close#59233
This commit extends the set of events understood by the
profiler integrated with the Angular time. The set got
extended to account for the recently added functionality
and mark entry point to the code execution points.
The new set of events can be visualised by the Angular
DevTools or other profiler integrations.
PR Close#59183
When setting `"useDefineForClassFields": false`, static fields are compiled within a block that relies on the `this` context. This output makes it more difficult for bundlers to treeshake and eliminate unused code.
PR Close#58297
with latest signal apis there are duplicates dependencies are shown in injected services, this PR filters the depdencies by token and value
PR Close#57564
We've been seeing some reports about Angular DevTools being unable to detect applications running in dev mode.
This commit adds more context to the error message displayed when development mode is not detected and offers some possible resolutions.
Displays 3 common reasons why DevTools fails to detect an application running in dev mode. Links directly to angular.dev for relevant configurations.
Links to the Angular DevTools issue template if none of the suggestions work.
PR Close#57861
Previously, when "Hide injectors with no providers" was toggled, it is possible for the injector tree visualizer to have no Element injectors to visualize. This caused a bug in the slicing logic that splits apart the environment and element injectors from DI resolution paths within the injector tree component in Angular DevTools.
Now, this logic is correctly handled when there are no element injectors to visualize.
PR Close#57442
Previously, if an application had DOM Nodes injected into it from other frames, DevTools would fail to parse component trees with the render tree strategy properly because of an instanceof Node check that the framework performs.
Now we check for instanceof Node before even calling framework debug APIs on DOM nodes so that we can skip nodes that come from other frames entirely.
PR Close#57518
When a browser extension is updated it becomes invalidated on currently open pages. If that extension then tries to send a message to those pages through `chrome.runtime.sendMessage(..)` then an error is thrown in the console
For Angular DevTools, this results in spamming the console with "Uncaught Error: Extension context invalidated." errors.
This commit catches that error and removes the event listener that triggers the `chrome.runtime.sendMessage(...)` call.
PR Close#55697
This change is a proof of concept of how the new Chrome DevTools
Performance extension API (https://bit.ly/rpp-e11y) can be used to
surface Angular runtime data directly in the Chrome DevTools Performance
panel.
Specifically, it implements the following changes:
1. Use the profiling status notification API to toggle the Timing API:
The notification API is implemented under the
chrome.devtools.performance extension namespace and consits of two
events: ProfilingStarted and ProfilingStopped, dispatched when the
Performance panel has started and stopped recording, respectively. This
API is used to enable the Timings API when the recording has started in
the Performance panel and disable it when recording has stopped.
2. Use the User Timings `detail` field format specification of the
Performance extension API
(https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/User_timing)
to inject data collected by the Angular Profiler into the
Performance panel timeline. Angular Profiler uses several hooks to
measure framework tasks like change detection. With this change, this
measurements are visible in the same context as the runtime data
collected by the browser in the Performance Panel timeline.
Note: to enable the user timings to be collected in the first place, one
needs to open the Angular DevTools panel so that the related artifacts
are loaded in the page. This shortcoming can be fixed in a follow up so
that the extra step isn't necessary.
PR Close#55805
This PR replaces all links available within the devtools to point
to the new docs.
The links to Input/Output (decorators) have been replaced with
their function (signal) counterparts: input, output.
PR Close#56138
This stamping is interfering with publishing to the Firefox addons store by brining in the entirety of the `.git` directory as part of the source code necessary for a reproducible build, which Firefox requires as part of it's approval process.
In it's place, we are now using the extension version pulled from the manifest.
PR Close#55694
This key comes from the release build of the Chrome extension. Setting it here configures the extension ID of a local build to match the extension ID of the public release. This makes Chrome recognize that local builds are the same extension leading to more intuitive behavior. It's also useful for allowlists of extension IDs to keep the local ID consistent.
PR Close#55639
In some cases the height of the viewport wasn't calculated correctly because of extension tabs quirks. This commit fixes this issue.
Fixes#53704
PR Close#54912
Mozilla requires add-ons to have reproducible builds and this is managed directly by human reviewers and need to understand how to build Angular DevTools correctly. This commit defines a reproducible way of building Angular DevTools which is useful for reviewers and contributers.
The actual changes I made include:
1. Moving local development content into `devtools/README` (deleting `devtools/DEVELOPING.md`) and explicitly stating the Node version as well as global Yarn install to be clear about the correct way to build the extension. This should make it easier for reviewers to understand and reproduce builds.
2. Moving release instructions to a separate doc to reduce noise as well as making some minor clean ups there.
I briefly considered pointing reviewers at a new `devtools/docs/reviewers.md` doc, but decided against it because I want these instructions to be maintained in a single location where contributors and reviewers use the same content. This way any changes don't miss one of these sets of users. If reviewers have trouble with this format (dev builds isn't useful to reviewers and some content is repeated from other docs for contributors) then we can consider splitting out to a separate `reviewers.md` file. But until then, I'd like to try sharing this content and see how it works out in practice.
PR Close#55406
Angular DevTools depends on many modern Angular features in order to function. As a result, at present the last officially supported version is v12. Angular DevTools may function for some Angular 9, 10 and 11 applications, but they are not officially supported.
This commit fixes an issue where DevTools would not inject a backend script into an Angular application if it detected it was below version 12. This backend script is important because it's used to inform the DevTools panel that the inspected application is in fact Angular, but that it is not on a supported version.
Angular 9, 10 and 11 applications that successfully have Angular DevTools initialize will now have a red highlight and tooltip on their version number, informing the user that they are using Angular DevTools on a version of Angular that is no longer supported.
Angular DevTools for applications that are below version 9 will continue to display the "Angular Devtools supports Angular versions 12 and above" message.
PR Close#55233
`Object.getPrototypeOf(obj)` returns `null` if `obj` is an empty object. `Object.getOwnPropertyDescriptors` throws on `null`/`undefined`
PR Close#55061
Previously, a race condition could cause DevTools to enter a state where it can't detect an application on reload. This was caused by a sequencing issue between the content script connection, the devtools panel connection and an event "backendReady" that lets DevTools know when a particular frame is ready to be inspected.
This commit replaces the previously stored backendReady boolean with a promise, so that the devtools panel can eventually run a callback to connect to a content script when that content script emits it's backendReady message.
PR Close#54805
This provides some more information on how to release and notably includes commands for zipping extension code and source code, which can otherwise be tricky to get exactly right.
PR Close#54525
In the Angular DevTools Chrome DevTools page:
- Angular DevTools is able to ask the background script to list each frame that has been registered on a page.
- Angular Devtools is able to ask the background script to "enable" the connection on a particular frame. This enables the messaging between the content script <-> background script <-> devtools page
- Implements detection of non unique urls on the inspected page
Limitations:
- The `inspectedWindow.eval` API is only able to target frames by frameURL. This means some features that integrate with Chrome DevTools like inspect element and open source will not be available when inspecting frames that do not have a unique url on the page.
PR Close#53934
Modifies the messaging layer of devtools to allow for switching communication between frames on a page. When served as a browser extension.
Design:
- When a page renders, DevTools installs a content script onto it through it's manifest file. The all_frames option is used here to install this script onto every frame in a page.
- When Angular is detected, the content script will install a backend script into it's frame.
- Each content script / backend script pairing is kept track of in the background script. This pairing represents an angular devtools context in a particular frame.
- Angular DevTools is able to ask the background script to list each frame that has been registered on a page.
- Angular Devtools is able to ask the background script to "enable" the connection on a particular frame. This enables the messaging between the content script <-> background script <-> devtools page
Limitations:
- The `inspectedWindow.eval` API is only able to target frames by frameURL. This means some features that integrate with Chrome DevTools like inspect element and open source will not be available when inspecting frames that do not have a unique url on the page.
PR Close#53934
This commit adds hydration informations to the devtools.
* List of hydrated/hydrated components
* Shows hydration overlays
* Shows hydration errors for NG0500, 501 & 502
PR Close#53910
The devtools now support signals.
Writable signals of primitives are editable.
Object Signal and other non-writable signals (like computed) are not editable.
Co-authored-by: Tomasz Ducin <tomasz.ducin@gmail.com>
PR Close#53269
These docs are out of date with how we currently build devtools in dev mode and as a browser extension. This commit brings these docs up to date.
PR Close#53948
This PR provides strict type definition for the window.ng object used
for both console debugging and devtools. `GlobalDevModeUtils` now
gathers all type information about all methods exposed on window.ng.
PR Close#53439
The version of rxjs used to build the repository has been updated to v7.
This required only minimal changes to the code. Most of which were type
related only due to more strict types in v7. The behavior in those cases
was left intact. The most common type related change was to handle the
possibility of `undefined` with `toPromise` which was always possible with
v6 but the types did not reflect the runtime behavior. The one change that
was not type related was to provide a parameter value to the `defaultIfEmpty`
operator. It no longer defaults to a value of `null` if no default is provided.
To provide the same behavior the value of `null` is now passed to the operator.
PR Close#53500
Enabling `strict` is part of an effort to improve the quality of the devtools code base.
One of the direct side effect is to enable `noImplicitAny`, `strictPropertyInitialization` and `strictBindCallApply`.
This commit also replaces `fullTemplateTypeCheck` with `stringTemplates`.
PR Close#53340
In some injectors, there are LOTS of providers, making it slightly inconvenient to search for a certain one. This commit introduces a search-by-token for providers of a specific injector.
PR Close#53313
Added 2 tiny improvements:
- instead of "Symbol()", "Symbol(DESCRIPTION)" is displayed
- ECMAScript Maps are distinguished
Additionally:
- PropTypes has been moved to a separate file
- Simple unit tests covering each PropType except for PropType.Unknown
PR Close#53167
Previously, some versions of Angular 16.1.x that had 3/4 of the new DI debug APIs would enter a code path that required them to have access to the 4th.
Now DevTools checks for the existence of all 4 explicitly before going down this code path.
PR Close#52791
Previously transformInjectorResolutionPathsIntoTree returned an array, now it returns a tree node so we update the test cases to reflect that.
PR Close#52489
Previously only the trackpad could be used to navigate this view.
Now we can zoom and pan around using our mouse wheel and scroll.
Additionally, this commit fixes many issues related to the visualization of the injector graph visualization, allowing it to be more compact without impacting legibility and minimizing edge collisions in larger graphs.
PR Close#52489
Our algorithm for discovering the injector graph of an application involves calculating resolution paths for each angular node on a page, and then using those paths to construct the underlying tree.
Along the we way we perform many expensive computations that are candidates for optimization through caching. This commit implements this caching, resulting in a substantial increase in performance for large applications.
PR Close#52489
Implements a feature allowing users to visualize multiproviders as one row in the providers table.
Also enables the user to log to console any provider in the table. This log includes information about the provider selected, the injector it was configured in, and also calls `Injector.get(Token)` to determine the value the provider evaluates to in it's injector.
PR Close#52489
Previously this was the only page that used the inspector, so we automatically changed the tab out of convenience.
Now, the injector tree tab also does uses the inspector for some functionality, so we disable this behaviour.
PR Close#52489
While `performance.mark` is available on all supported browsers and node.js version this API is not available in JSDOM which is used by Jest and Cloudflare worker.
PR Close#52505
Creates set of unit tests for each function in the data transformation pipeline that enables injector metadata to be visualized as d3 graphs.
PR Close#51719
This commit introduces 2 new features into DevTools.
Directive level dependency inspection: Users can now view which dependencies their directives have injected in the property viewer tab. This view displays not only the dependency but also the resolution path that was used to service the injection.
Injector graph inspection: Users can now view a visualization of the element and environment hierarchies in their application. These trees are displayed separately but on the same page in the Injector Tree tab. User can click on individual injectors to view a list of all the providers configured in that injector, as well as highlight the resolution path from that injector to the root (with the corresponding environment injector connection highlighted as well).
PR Close#51719
In Devtools bar chart we can see the total time for all the directive instances in one change detection run.
This PR changes the bar chart to display the total count and time for all directive instances instead of showing the time for each directive instance separately in one change detection run.
PR Close#50866
Currently internally Angular has some customized tsconfig files, because we don't align with the tsconfig of the rest of g3. These changes enable `noImplicitReturns` and `noPropertyAccessFromIndexSignature` to align better with the internal config.
PR Close#51728
Currently the label showing the component name is always positioned from the bottom/right edge of the element which may be outside of the viewport. These changes add some logic to fall back to a different position so that the label is always visible.
I've also cleaned the `highlighter.ts` file up a bit.
Fixes#48479.
PR Close#50656
The existing DevTools demo app that is used for developing on DevTools is exclusively an NgModule application. This commit creates a copy of the old demo app but with no NgModules and only standalone APIs/Components/Directives/Pipes
PR Close#48533
We do this because of a bug caused by https://github.com/evanw/esbuild/issues/2950 and a recent change to how angular static properties are attached to class constructors. Targeting esnext or es2022 will cause the static initializer blocks that attach these static properties on class constructors to reference a class constructor variable that they do not have access to.
Because of this we explicitly target es2020 in our Angular DevTools builds.
PR Close#50086
Since DevTools' Angular framework dependencies are built from local files, they are always up to date. [Recently](https://github.com/angular/angular/pull/49332) these dependencies started being published as fesm2022 instead of fesm2020. We also have an Angular dependency `ngx-flamegraph` that was built and published as fesm2020.
The easiest fix to make sure all of our Angular based dependencies are processed by the linker would be to update the filterPaths field in that file from `/fesm2020/` to `/fesm2020|fesm2022/`. When v16 releases, we can update ngx-flamegraph and publish it with the new APF, letting us change filterPaths to just `/fesm2022/`.
PR Close#50086
DevMode is when the ng debug object is available. `Optimization:true` is responsible for treeshaking everything behind `ngDevMode`.
Fixes#48968
PR Close#48970
`RouterTestingModule` is not needed as of v16. Instead, TestBed
automatically provides `MockPlatformLocation` in order to help test
navigations in the application. The location mocks in the
RouterTestingModule aren't necessary anymore.
There doesn't appear to be any real documentation around
`RouterTestingModule` other than the API docs.
PR Close#49427
With this commit, Sets are displayed with the label Set(#) where # is the size of the set. They are not expandable/editable though.
Partial fix for #49312
PR Close#49316
`entryComponents` have been deprecated since version 9, because with Ivy they weren't necessary. These changes remove any remaining references.
BREAKING CHANGE:
* `entryComponents` has been deleted from the `@NgModule` and `@Component` public APIs. Any usages can be removed since they weren't doing anyting.
* `ANALYZE_FOR_ENTRY_COMPONENTS` injection token has been deleted. Any references can be removed.
PR Close#49484
The options to generate NgFactory and NgSummary files were added to Ivy for backwards compatibility with ViewEngine. Since ViewEngine was deprecated and removed, the NgFactory and NgSummary files are no longer used as well.
This commit drops obsolete options to generate NgFactory and NgSummary files. Also, the logic that generates those files is also removed.
PR Close#48268
Previously the DevTools demo app and browser app had duplicated styles in their respective styles.scss files.
This commit creates a global styles.scss that is imported with sass @use into the demo and browser app styles.scss files. This will prevent any issues where css changes to one are missed in the other. Also reduces duplication of material css theme definitions by consolidating it inone place. The respective styles.scss files for the demo app and browser app continue to exist incase those need environment specific css. For example the browser app requires that height: 100% is set on a document in order to render properly in a browsers devtools tab.
PR Close#49001
Previously, a createConfig helper function was created to consolidate common esbuild configurations for DevTools. This function is asynchronous, but when it was used to set the configuration in various esbuild config files, it was used as if it was synchronous.
This commit fixes this issue by wrapping the output of the function in await, so that it propagates the configurations to esbuild correctly.
PR Close#48762
Since the `defaults.bzl` repo-wide macros are now supporting ESM,
the special spec-bundle logic from `devtools` can be removed.
Also the esbuild configurations need to be updated to account
for the recent dev-infra build-tooling changes. Also properly
now ensures that `aysnc/await` is downleveled for ZoneJS compatibility.
PR Close#48521
In the #48216 Material deps were updated to v15,
but the components and modules in DevTools were not
updated to MDC nor replaced with the legacy definitions.
PR Close#48420
On Firefox, Angular DevTools was breaking the XML display because of the script injected
Based on contentType, we won't inject that script anymore
Fixes#48017
PR Close#48021
Previously we built DevTools for all browsers with version 2 of the manifest file format.
This commit includes a number of refactors and API additions that will enable us to build DevTools with version 3 of the manifest file format.
The manifest v3 build of Angular DevTools has been tested on Chrome, Edge, and Safari.
Notably, the Firefox version of Angular DevTools remains as a manifest v2 build. Firefox does not yet support manifest v3 in it's latest stable release. When Firefox makes this transition, a follow up PR will update the Firefox manifest file to version 3.
Because Firefox still needs v2, we need to keep some old v2 APIs around in our background page (service worker in v3) that will execute conditionally based on if the extension was built for v2 or v3. This is determined with the chrome.runtime.getManifest().manifest_version API.
PR Close#47575
Previously, you could inspect the source code of a component but not a directive. This commit adds functionality to inspect source code for directives as well. Now you will see the inspect icon on the header component of each directive on a selected element.
PR Close#47334
This option has no longer any effect as Ivy is the only rendering engine.
BREAKING CHANGE: Angular compiler option `enableIvy` has been removed as Ivy is the only rendering engine.
PR Close#47346
The dev-infra build tooling is now decoupled from `ng-dev`. This will
make it easier to update `ng-dev` without necessarily needing to upgrade
the whole build system, Bazel etc. This is useful when e.g. new release
tool features have been added and should also be ported to active LTS
branches.
PR Close#46976
As part of the initial devtools migration (moving it into this repo with
Bazel), we copied some of the Bazel Karma debug config code since it was
not available from the shared dev-infra repo. We already switched to the
shared code that is now available, but were missing an now-unused file.
PR Close#46491
Replaces the copied `spec_bundle` rule in the devtools folder with the
one provided by dev-infra. Initially we couldn't use the rule because
it wasn't available / and also later didn't work with the linker
version from `compiler-cli` built from `HEAD`.
PR Close#46437
With the introduction of standalone components, it is no longer guaranteed that getAllAngularRootElements will be available on the global object. This PR removes the dependency on this function so that DevTools can continue to work for Angular applications that use `bootstrapApplication`.
PR Close#45983
Add support to material design icons in offline mode for Angular Devtools. Self hosting the web font so icons are loaded regardless of network connection.
Bring the font file as well as its corresponding css file from third_party repo through bazel into shell-browser directory while building.
PR Close#45743
Uses `createEsbuildAngularOptimizePlugin` from dev-infra-private and passes in `GLOBAL_DEFS_FOR_TERSER_WITH_AOT` into a new esbuild prod configuration. Notably, this removes references to `ngDevMode` from the final build and enables minification.
PR Close#45886
In Angular v12 we introduced debugging APIs sufficient for DevTools.
Prior to that Angular DevTools accesses the logical data structures of
Ivy directly, which sometimes produces suboptimal results and skips
dynamically inserted content.
With the end of v11's LTS, we'll support only Angular v12 and up.
PR Close#45883
With the introduction of many new devtools extensions APIs, it is now possible to install Angular DevTools in Safari.
This commit details how to convert an Angular DevTools build to a Safari web extension with Xcode and `xcrun safari-web-extension-converter `
PR Close#45763
Adds support for TypeScript 4.7. Changes include:
* Bumping the TS version as well as some Bazel dependencies to include https://github.com/bazelbuild/rules_nodejs/pull/3420.
* Adding a backwards-compatibility layer for calls to `updateTypeParameterDeclaration`.
* Making `LView` generic in order to make it easier to type the context based on the usage. Currently the context can be 4 different types which coupled with stricter type checking would required a lot of extra casting all over `core`.
* Fixing a bunch of miscellaneous type errors.
* Removing assertions of `ReferenceEntry.isDefinition` in a few of the language service tests. The field isn't returned by TS anymore and we weren't using it for anything.
* Resolving in error in the language service that was caused by TS attempting to parse HTML files when we try to open them. Previous TS was silently setting them as `ScriptKind.Unknown` and ignoring the errors, but now it throws. I've worked around it by setting them as `ScriptKind.JSX`.
PR Close#45749
