Update the `esbuild` macro in devtools to use
`external` sourcemaps by default and remove the ability to override the `sourcemap` and `sources_content` options.
This change is necessary to ensure that the build is deterministic and 100% reproducible as otherwise Firefox will not publish the build.
Previously these tests would run automatically when Angular DevTools lived in another repo. These files have continued to live here but have not been running automatically on each PR.
Now, these test files have been revived to run properly with our changes since the repo merge. This is a first step to reviving our e2e testing.
Next steps include writing cypress tests for new features like Injector Graph, Router tree, signals visualizations, etc.
PR Close#61972
This seems to be helpful for Mozilla reviewers to reproduce the build without encountering Bazel errors like:
```
Server terminated abruptly (error code: 14, error message: 'Socket closed', log file: '/home/parallels/.cache/bazel/_bazel_parallels/ae710c6507eb251f9511ac4228641059/server/jvm.out')
```
`--local_ram_resources` is also useful, but I'm not sure what to set it to by default or how necessary it is, so let's just start with `--jobs 4` for now. The 4 is arbitrary as I don't have insight into how many jobs are actually appropriate, but we can go with this for now and tweak the number later if it still causes issues.
PR Close#62015
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
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
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
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
