This commit adds an import to the `ng_dev_mode.ts` file that augments
`global` to have types for `ngDevMode`.
Notably this change is currently not needed because the file is loaded
by `ts_library` through `tsconfig#files`— but in a separate PR we are
switching the target to `ts_project` which no longer loads all Bazel
dependency files via `tsconfig#files`; resulting in the ambient types no
longer magically being available.
PR Close#61365
fix new global layout issues, and make other pages adhere to the new centered layout like cli ref page, cli ref details, api ref details pages
PR Close#61256
As we roll out more PRs that migrate to `ts_project`, we need to make
sure that we don't break existing `tsec` targets. This PR copies the
original `tsec` Starlark code and adjusts it to work with the interop.
Note that we don't patch as this would unnecessarily complicate this
file that only exists during migration. Long-term, after migration, we
either need to consider switching to the new ESLint plugin that is being
worked on (I'm in contact with the team), or we send a CL to update the
Tsec Starlark code to keep our changes minimal and avoid scope increase.
PR Close#61336
This aligns with how angular/components marks their hidden APIs.
`@nodoc` has been broken since the switch to adev, this change should
properly hide the APIs again.
PR Close#61196
As part of the Bazel toolchain migration we noticed that implicit types
generated by the TypeScript compiler sometimes end up referencing types
from other packages (i.e. cross-package imports).
These imports currently work just because the Bazel `ts_library` and
`ng_module` rules automatically inserted a `<amd-module
name="@angular/x" />` into `.d.ts` of packages. This helped TS figure
out how to import a given file. Notably this is custom logic that is not
occuring in vanilla TS or Angular compilations—so we will drop this
magic as part of the toolchain cleanup!
To improve code quality and keep the existing behavior working, we are
doing the following:
- adding a lint rule that reduces the risk of such imports breaking. The
failure scenario without the rule is that API goldens show unexpected
diffs, and types might be duplicated in a different package!
- keeping the `<amd-module` headers, but we manually insert them into
the package entry-points. This should ensure we don't regress
anywhere; while we also improved general safety around this above.
Long-term, isolated declarations or a lint rule from eslint-typescript
can make this even more robust.
PR Close#61316
take the full width of the page for all the pages that use docs-viewer, also reserve an area for table of contents on-demand
Resolves: #52648
PR Close#58831
Migrates `manual_api_docs` to `rules_js`. Since compiler CLI is ESM
compiled but doesn't have extensions, we can either bundle or simply use
the dependency as type only. This is easier and sufficient for this
use-case.
PR Close#61237
Updates the name which accidentally remained unchanged from when I
copied it from the CLI help script
Also marks the PR for merge immediately. The caretaker can sanity check
it, approve it, and merge it.
PR Close#61195
We don't need this tooling anymore because we are already validating
that there are no circular dependencies via the `ng-dev` tooling that
checks `.ts` files directly.
Also these tests never actually failed to my knowledge.
PR Close#61209
Replaces incorrect use of GitHub Actions expression syntax `${{CURRENT_BRANCH }}` inside a run block with proper bash variablesyntax `$CURRENT_BRANCH`, preventing 'Unrecognized named-value' errors.
PR Close#61212
This workflow addresses a limitation with Renovate's behavior in fork mode. Renovate does not automatically sync non-default branches in forked repositories.
This workflow automates syncing forked non-default branches with their upstream counterparts. This ensures Renovate can detect and apply updates to these branches, maintaining up-to-date dependencies across all relevant branches.
PR Close#61201
The `false` behavior has existed for a long time but hasn't really
been documented. It's also not _quite_ what the browser would do.
Finally, the page explicitly discourages the implicit `false` way
of preventing default. Biggest motivation (beyond code clarity) are
potential footguns like `(click)="myProp=x()"` which happens to prevent
default behavior iff `x()` happens to return `false`.
Fixes https://github.com/angular/angular.io/issues/2568
PR Close#61184
Alex Rickabaugh