Paul Gschwendtner 9dd3f0344f
Further clean-up rules_nodejs npm workspace and remove yarn.lock (#29779)
* build: disconnect `@npm` workspace from main project

This will speed up significantly as we don't need to fetch all
dependencies again just for the `@npm` repository that is at this point
only leveraged by the `ng_package` rule for some of its dependencies.

This commit allows us to drop the `yarn.lock` and Aspect lock files, and
allows us to independently migrate `ng_package` to `rules_js`.

It also allows us to drop the `_rjs` TS interop layer in follow-up commits.

* build: drop `_rjs` suffix from `ts_project` targets

We don't need the `ts_project` interop in principle
at this point. We only have one remaining instance left for the SSR
`ng_package` integration. This commit cleans up all usages.

* build: remove yarn

* build: avoid duplicated dependencies at top-level

`rules_js` seems to be sensitive if there are similar versions of the same
package installed, but with differently matched peer dependencies. This
is fine because we can (and should long-term) move those dependencies to
their package-local `package.json` files. This commit unblocks the
migration and highlights how we can move deps to the individual packages
in the future.

* build: update checkout github action

This will allow us to use pnpm.

* build: update node to avoid strict-engines error caused by `npm`

Avoids:

```
Lockfile is up to date, resolution step is skipped
 ERR_PNPM_UNSUPPORTED_ENGINE  Unsupported environment (bad pnpm and/or Node.js version)

Your Node version is incompatible with "npm@11.2.0".

Expected version: ^20.17.0 || >=22.9.0
Got: v20.11.1
```

Note that we won't update the WORKSPACE test version as that would mean
we need to update the Node engines for shipped packages; and we can't do
this right now without introducing a breaking change.

* build: fix missing dependency for spec bundling

The beasties JS sources weren't available for bundling in the
`bazel-bin`, and this surfaced in RBE. This commit fixes this.
2025-03-11 10:05:52 +01:00
..

Angular Compiler Webpack Plugin

Webpack 5.x plugin for the Angular Ahead-of-Time compiler. The plugin also supports Angular JIT mode. When this plugin is used outside of the Angular CLI, the Ivy linker will also be needed to support the usage of Angular libraries. An example configuration of the Babel-based Ivy linker is provided in the linker section. For additional information regarding the linker, please see: https://angular.dev/tools/libraries/creating-libraries#consuming-partial-ivy-code-outside-the-angular-cli

Usage

In your webpack config, add the following plugin and loader.

import { AngularWebpackPlugin } from '@ngtools/webpack';

exports = {
  /* ... */
  module: {
    rules: [
      /* ... */
      {
        test: /\.[jt]sx?$/,
        loader: '@ngtools/webpack',
      },
    ],
  },

  plugins: [
    new AngularWebpackPlugin({
      tsconfig: 'path/to/tsconfig.json',
      // ... other options as needed
    }),
  ],
};

The loader works with webpack plugin to compile the application's TypeScript. It is important to include both, and to not include any other TypeScript loader.

Options

  • tsconfig [default: tsconfig.json] - The path to the application's TypeScript Configuration file. In the tsconfig.json, you can pass options to the Angular Compiler with angularCompilerOptions. Relative paths will be resolved from the Webpack compilation's context.
  • compilerOptions [default: none] - Overrides options in the application's TypeScript Configuration file (tsconfig.json).
  • jitMode [default: false] - Enables JIT compilation and do not refactor the code to bootstrap. This replaces templateUrl: "string" with template: require("string") (and similar for styles) to allow for webpack to properly link the resources.
  • directTemplateLoading [default: true] - Causes the plugin to load component templates (HTML) directly from the filesystem. This is more efficient if only using the raw-loader to load component templates. Do not enable this option if additional loaders are configured for component templates.
  • fileReplacements [default: none] - Allows replacing TypeScript files with other TypeScript files in the build. This option acts on fully resolved file paths.
  • inlineStyleFileExtension [default: none] - When set inline component styles will be processed by Webpack as files with the provided extension.

Ivy Linker

The Ivy linker can be setup by using the Webpack babel-loader package. If not already installed, add the babel-loader package using your project's package manager. Then in your webpack config, add the babel-loader with the following configuration. If the babel-loader is already present in your configuration, the linker plugin can be added to the existing loader configuration as well. Enabling caching for the babel-loader is recommended to avoid reprocessing libraries on every build. For additional information regarding the babel-loader package, please see: https://github.com/babel/babel-loader/tree/main#readme

import linkerPlugin from '@angular/compiler-cli/linker/babel';

exports = {
  /* ... */
  module: {
    rules: [
      /* ... */
      {
        test: /\.[cm]?js$/,
        use: {
          loader: 'babel-loader',
          options: {
            cacheDirectory: true,
            compact: false,
            plugins: [linkerPlugin],
          },
        },
      },
    ],
  },
};