angular / dev-infra

Angular Development Infrastructure

Angular - The modern web developer's platform

Angular is a development platform for building mobile and desktop web applications
using TypeScript/JavaScript and other languages.

angular.dev

Contributing Guidelines · Submit an Issue · Blog

   

---

Documentation

Get started with Angular, learn the fundamentals and explore advanced topics on our documentation website.

• Getting Started
• Architecture
• Components and Templates
• Forms
• API

Advanced

• Angular Elements
• Server Side Rendering
• Schematics
• Lazy Loading
• Animations

Local Development

To contribute to the Angular Docs, check out the Angular.dev README

Development Setup

Prerequisites

• Install Node.js which includes Node Package Manager

Setting Up a Project

Install the Angular CLI globally:

npm install -g @angular/cli

Create workspace:

ng new [PROJECT NAME]

Run the application:

cd [PROJECT NAME]
ng serve

Angular is cross-platform, fast, scalable, has incredible tooling, and is loved by millions.

Quickstart

Get started in 5 minutes.

Ecosystem

• Angular Command Line (CLI)
• Angular Material

Changelog

Learn about the latest improvements.

Upgrading

Check out our upgrade guide to find out the best way to upgrade your project.

Contributing

Contributing Guidelines

Read through our contributing guidelines to learn about our submission process, coding rules, and more.

Want to Help?

Want to report a bug, contribute some code, or improve the documentation? Excellent! Read up on our guidelines for contributing and then check out one of our issues labeled as help wanted or good first issue.

Code of Conduct

Help us keep Angular open and inclusive. Please read and follow our Code of Conduct.

Community

Join the conversation and help the community.

• X (formerly Twitter)
• Discord
• Gitter
• YouTube
• StackOverflow
• Find a Local Meetup

Love Angular? Give our repo a star ⭐ ⬆️.

dev-infra's Issues

Ivy presubmit script doesn't run with Ivy if ng_module.bzl is edited

If the presubmit diff edits the ng_module.bzl file in some way, the diff from the flip CL isn't applied to the file, and the presubmit runs with VE instead of Ivy.

Set up auto code formatting

Automatically deploy a `next` version of docs site on commits to master

Set up Windows CI

• Set up on framework
• Set up on components
• Set up on cli

[meta] New releases should post notifications in resolved issues/merged PRs

🚀 Feature request

When a new release is published, it includes information in the changelog about which PRs are included and which issues are fixed in the new version. The publishing process should include automated notification hooks so that those following the issues/PRs will see the message and know that it's resolved.

I'm making an issue for this per this comment from @IgorMinar.

Security Policy violation Branch Protection

Security Policy Branch Protection is out of compliance, status:
PR Approvals not configured for branch main

Issue created by Allstar. https://github.com/ossf/allstar

Automatically cherrypick PRs to target branches after merge

Blocked by #15

Template Lint

For the components repo, we want to be able to lint Angular templates. CLI would probably benefit from this as well, and maybe framework just for tests.

Context: angular/components#18588

Separate aXe tests from e2e tests

Cut releases from CI

Define the lifecycle of a PR

Provide common workspace setup

Provide a common importable function to setup the WORKSPACE for downstream repositories, retrieving necessary dependencies and setting up things like node modules.

This would allow us to sychronize the versions of node and rules_nodejs being used by repositories.

Before:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

# Fetch rules_nodejs so we can install our npm dependencies
http_archive(
    name = "build_bazel_rules_nodejs",
    sha256 = "5c40083120eadec50a3497084f99bc75a85400ea727e82e0b2f422720573130f",
    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/4.0.0-beta.0/rules_nodejs-4.0.0-beta.0.tar.gz"],
)

load("@build_bazel_rules_nodejs//:index.bzl", "node_repositories", "yarn_install")

node_repositories(
    node_repositories = {
        "14.17.0-darwin_amd64": ("node-v14.17.0-darwin-x64.tar.gz", "node-v14.17.0-darwin-x64", "7b210652e11d1ee25650c164cf32381895e1dcb3e0ff1d0841d8abc1f47ac73e"),
        "14.17.0-linux_amd64": ("node-v14.17.0-linux-x64.tar.xz", "node-v14.17.0-linux-x64", "494b161759a3d19c70e3172d33ce1918dd8df9ad20d29d1652a8387a84e2d308"),
        "14.17.0-windows_amd64": ("node-v14.17.0-win-x64.zip", "node-v14.17.0-win-x64", "6582a7259c433e9f667dcc4ed3e5d68bc514caba2eed40e4626c8b4c7e5ecd5c"),
    },
    node_version = "14.17.0",
)

yarn_install(
    name = "npm",
    package_json = "//:package.json",
    yarn_lock = "//:yarn.lock",
)

After:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

# Fetch rules_nodejs so we can install our npm dependencies
http_archive(
    name = "angular-dev-infra",
    sha256 = "...",
    urls = ["https://github.com/angular/dev-infra-private-builds/..."],
)

Create a npm retagging script

Create script to change the dist-tag values on a set of NPM packages. Usage is for situations like releasing to @next initially and then wanting to just promote the package to @latest

Example: One script that based on repo config would automatically set the tag on all of Components packages - @angular/{material,cdk,material-experimental,cdk-experimental,etc} all at one

Disallow feature commit messages without a scope

Example: feat: make mocha a zone module. (#34719)

All feature commits should have a scope. This has been problematic in angular/angular because some scopes should be omitted from the CHANGELOG (e.g. zone.js), but they can't be if the scope isn't listed.

The validation task that we use should catch this case and throw.

Automatically merge PRs once they become merge ready

Code formatting should be run on CHANGELOG.md during release

During the release process, when the new Changelog entry is generated and added to the CHANGELOG.md file, we should leverage the formatFiles function from ng-dev/format/format to format the newly modified CHANGELOG.md file.

This notably presents as a failure on CI for CLI as markdown files are formatted using prettier.

Migrate caretaker application to be public facing

Github Action to automatically rebase PR if possible

Validate and test packaged version of libraries

We currently have no automated tests for the actual npm package we produce. We should, at the very least, run our e2e tests against the real packages.

It would additionally be good to test the components against an Angular CLI application. It might be best, then, to change our e2e app to be an Angular CLI application.

Some other possibilities worth discussion:

• Creating a general angular-package-validator tool that we could use for all Angular-related projects.
• Clone and run the tests for angular.io and/or material.angular.io with the packages

Other related checks

• Ensure that the release doesn't include cdk/testing or material/testing

Open to other ideas here.

cc @josephperrott

Move to bazel for all builds and tests

• Move everything on framework
• Move everything on components
• Move everything on cli

Automatically keep package.json dependencies up to date

• Set up for Framework
• Set up for Componentse
• Set up for CLI

Create a new Job on Angular which would run profiling tests

See: angular/angular#33186

I would like to have a separate circle-ci job which would execute the profile_all.js to measure if the PR is making things better or worse.

1. Revert PR in job and run profile_all.js --write baseline.json
2. Restore PR in job and run profile_all.js --read baseline.json

For now this is enough to see if the number are stable/predictable.

Set up performance statistics for builds

Set up Remote Build Execution

• Set up on framework
• Set up on components
• Set up on cli

Markdown lint

I would like a markdown lint for the components repo, and we probably want this for other repos as well. Bonus points for a markdown formatter as good as (or close to) the one we have inside Google.

Some lints I care about:

• Using the correct headers (especially for integration with our docs site)
• Code fences have a valid language
• Max line length (100)
• Certain HTML tags (e.g. mat-, cdk-) used in paragraphs without code formatting

Enforce common linting rules

Automatically lock old/stale issues and PRs

• Framework
• CLI
• Components

Determine story/tooling for automatic code review assignment

Make a "no update" bot.

When someone posts to an issue a message like "Any updates?", the bot would immediately respond with something like

Updates will appear on this issue when progress is made. You
can subscribe to the issue for updates and use the "thumbs up"
reaction to register your interest.

<sub>_This automated message made by a bot_</sub>

Would have to have some rate limit to avoid trolls spamming it

Lint / sanity check bash scripts

We should check bash scripts for problematic patterns, particularly patterns that are inconsistent between macOS and Linux.

Migrate `google3` status check to use Github Action / ng-dev tooling

• Create ng-dev based tooling for checking if a list of files is being synced into google3
• Create Github Action to determine if the files changed in a repository sync as expected into google3

This is a migration away from the check being done in the ngbot

Investigate evergreen syncing of CLI in google3

Enforce minimum set of strictness flags

Track resource usage for our tools/packages/assets we publish

"PR action: rerun CI at HEAD" label doesn't trigger rebuilds on angular/angular

When I apply "PR action: rerun CI at HEAD" label to a pr on a/a repo, I see that the ng-bot removes the label (as expected), but doesn't trigger a rebuild of the PR on CircleCI.

Is there a known reason why this fails? Could this be fixed?

Easy way to sync Github issues to Jira

We've been doing a lot of manual porting from Github to Jira, which is probably not a good use of time. In the past, we had a Github label that we could apply if we wanted to sync something to Jira, which was super convenient. I think there may have been permissions issues that prevented us from doing this long-term, but it would be great if we could revisit how this might be possible.

Prompt selection of major or minor during branching off

During any usage of actions based off of BranchOffNextBranchBaseAction we should prompt the user to select whether the newly created branch should be a major or minor.

Automatically update current caretaker to Slack channel status

We used to have this for components, but it's still super useful. It helps non-Googlers know who to contact if there are issues with getting PRs merged.

fix(dev-infra): ensure PRs targeting a specific branch are not merged into other branches

In pr/merge/defaults/labels.ts > getDefaultTargetLabelConfiguration(), there should be a check to ensure that we don't try to merge a PR to latest/rc/next branches if the PR is targeting a specific branch (for example, here).

This was originally discussed in angular/angular#38656 (comment).

Automatically apply `breaking changes` label if PR contains breaking changes

The merge script currently requires developers to add BREAKING CHANGES: , or the breaking changes label when there are breaking changes. We should automatically add the label through a Github action if a breaking changes marker is found in a commit message.

Auto-label issues filed by Googlers

On components, we manually label issues from Googlers. It would be great if this were automated, though it would require cooperation with Google's OSPO.

Test pre-released packages interaction on CI during deployment process

We should have the ability to run a test of tests against the yet to be released versions of the npm packages. Might need to create a docker image that will set up a local NPM registry and test out each of the projects.
Example: When a major release is done, we should have the capability for Tools to run their tests against the x.0.0 framework release before its actually on NPM

Security Policy violation SECURITY.md

Security Policy SECURITY.md is out of compliance, status:
SECURITY.md not found.
Go to https://github.com/angular/dev-infra/security/policy to enable.

Issue created by Allstar. https://github.com/ossf/allstar

Github action that can be used to approve API golden files

Most of the time, people create a pull request and forget about approving/updating the API golden files. This is commonly seen on community PRs because creating a merge-ready PR involves a lot of steps.

It would be helpful if there is a way to update/approve the goldens through the Github UI. That way, one doesn't have to go back to a failing PR to update the goldens, and it can be useful for community PRs where goldens need to be updated (saving time; so that one doesn't need to fetch&push the PR)

Set up Remote Caching

• Set up on framework
• Set up on components
• Set up on cli

Automate onboarding to the Angular Org/Team

Define the lifecycle of an Issue

Automatically check cherrypicking of PRs to target branches

Push components google3 presubmit test results as a github status

ci(angular/dev-infra): add CI checks to ensure `lock-closed` action is built correctly

The problem

Currently, the angular/dev-infra repository relies on a pre-commit git hook for building the lock-closed action, in order to ensure that the changes made in the source code (e.g. src/main.ts) will also be included in the built script that is actually used when running the action (i.e. lib/bundle.js).

However, it is easy to miss this step (for example if someone submit a PR via the GitHub UI or commits review suggestions via the GitHub UI or has git hooks disabled, etc.).

This can result in issues such as angular/angular#39358, where the fix is in the source code but not in the built script (that is actually used).

The solution

Introduce CI checks to angular/dev-infra that would ensure that the built script (lib/bundle.js) is indeed up-to-date with the source code (src/main.ts).