Paul Gschwendtner 5fd1cb56ab build: update dev-infra and rework windows native testing
As part of go/ng:windows-dev-future, we are changing how our
infrastructure supports Windows build & testing. Clearly:

- we will still support contributors on Windows, and we believe we will
  be improving and streamlining the experience here
- we will continue testing the Angular CLI for our Windows users. We are
  aware of the many Windows users using the `ng` CLI.

What is changing? We are no longer actively working towards a Bazel infrastructure
that supports native Windows building and testing. There are currently
two ways to contribute to Angular on Windows. That is via WSL, or via
e.g. native Windows cmd.exe, with Git Bash on top. We acknowledge that
the latter worked sometimes, but we also realize it very often breaks as
nobody on our team uses, verifies it, and it introduces extra complexity
because Bazel on Windows is quite disconnected from Linux/Mac (e.g. no
sandboxing). Going forward, to improve our team's effectiveness, and
improve our stability guarantees for Windows (and Windows contributors),
we are actively discouraging the use of Git Bash for contributing to
Angular; but instead ask for WSL to be used. I can speak as one of the
few long-term team members that have worked on Windows (without WSL) most
of my time, that WSL is great and the contributing experience is much
smoother and also easier to "guide". It's a positive change because we
won't be suggesting "two ways to contribute on Windows", where in
reality one is very brittle and can break at any time!

---

For testing of the Angular CLI: We will continue to maintain the
capability to cross-compile via Bazel with Windows as the target
platform. This allows us to build the e2e tests for Windows, and run
them natively outside WSL to ensure native Windows `ng` CLI testing!
This is what this change mostly does.

Notably, two things are missing here and will be followed up:

- caching of the e2e tests on Windows is not properly functioning yet.
- caching of the WSL node modules + nvm is not working properly yet.

Other than that, we are seeing very similar timing and results of the
Windows tests, so this change unblocks our `rules_js` migration.
2025-03-03 21:44:50 +01:00
..
2021-04-28 16:05:49 -07:00

Core

Shared utilities for Angular DevKit.

Exception

Json

Schema

SchemaValidatorResult

export interface SchemaValidatorResult {
  success: boolean;
  errors?: string[];
}

SchemaValidator

export interface SchemaValidator {
  (data: any): Observable<SchemaValidatorResult>;
}

SchemaFormatter

export interface SchemaFormatter {
  readonly async: boolean;
  validate(data: any): boolean | Observable<boolean>;
}

SchemaRegistry

export interface SchemaRegistry {
  compile(schema: Object): Observable<SchemaValidator>;
  addFormat(name: string, formatter: SchemaFormatter): void;
}

CoreSchemaRegistry

SchemaRegistry implementation using https://github.com/epoberezkin/ajv. Constructor accepts object containing SchemaFormatter that will be added automatically.

export class CoreSchemaRegistry implements SchemaRegistry {
  constructor(formats: { [name: string]: SchemaFormatter} = {}) {}
}

Logger

Utils

Virtual FS

Workspaces

The workspaces namespace provides an API for interacting with the workspace file formats. It provides an abstraction of the underlying storage format of the workspace and provides support for both reading and writing. Currently, the only supported format is the JSON-based format used by the Angular CLI. For this format, the API provides internal change tracking of values which enables fine-grained updates to the underlying storage of the workspace. This allows for the retention of existing formatting and comments.

A workspace is defined via the following object model. Definition collection objects are specialized Javascript Map objects with an additional add method to simplify addition and provide more localized error checking of the newly added values.

export interface WorkspaceDefinition {
  readonly extensions: Record<string, JsonValue | undefined>;
  readonly projects: ProjectDefinitionCollection;
}

export interface ProjectDefinition {
  readonly extensions: Record<string, JsonValue | undefined>;
  readonly targets: TargetDefinitionCollection;
  root: string;
  prefix?: string;
  sourceRoot?: string;
}

export interface TargetDefinition {
  options?: Record<string, JsonValue | undefined>;
  configurations?: Record<string, Record<string, JsonValue | undefined> | undefined>;
  builder: string;
}

The API is asynchronous and has two main functions to facilitate reading, creation, and modifying a workspace: readWorkspace and writeWorkspace.

export enum WorkspaceFormat {
  JSON,
}
export function readWorkspace(
  path: string,
  host: WorkspaceHost,
  format?: WorkspaceFormat,
): Promise<{ workspace: WorkspaceDefinition }>;
export function writeWorkspace(
  workspace: WorkspaceDefinition,
  host: WorkspaceHost,
  path?: string,
  format?: WorkspaceFormat,
): Promise<void>;

A WorkspaceHost abstracts the underlying data access methods from the functions. It provides methods to read, write, and analyze paths. A utility function is provided to create an instance of a WorkspaceHost from the Angular DevKit's virtual filesystem host abstraction.

export interface WorkspaceHost {
  readFile(path: string): Promise<string>;
  writeFile(path: string, data: string): Promise<void>;
  isDirectory(path: string): Promise<boolean>;
  isFile(path: string): Promise<boolean>;
}

export function createWorkspaceHost(host: virtualFs.Host): WorkspaceHost;

Usage Example

To demonstrate the usage of the API, the following code will show how to add a option property to a build target for an application.

import { NodeJsSyncHost } from '@angular-devkit/core/node';
import { workspaces } from '@angular-devkit/core';

async function demonstrate() {
  const host = workspaces.createWorkspaceHost(new NodeJsSyncHost());
  const { workspace } = await workspaces.readWorkspace('path/to/workspace/directory/', host);

  const project = workspace.projects.get('my-app');
  if (!project) {
    throw new Error('my-app does not exist');
  }

  const buildTarget = project.targets.get('build');
  if (!buildTarget) {
    throw new Error('build target does not exist');
  }

  buildTarget.options.optimization = true;

  await workspaces.writeWorkspace(workspace, host);
}

demonstrate();