angular / angular/angular-cli

Support resolving architect builders relative to project

Ouverte
#20,453 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
area: @angular/cli feature feature: insufficient votes
Langage dominant
TypeScript
Étoiles
27k
Forks
11.8k
Merge moyen
14 h 23 min
PR mergées (30 j)
162

Description

# 🚀 Feature request

### Command (mark with an `x`)

- [ ] new
- [x] build
- [x] serve
- [x] test
- [x] e2e
- [ ] generate
- [ ] add
- [ ] update
- [x] lint
- [x] extract-i18n
- [x] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

### Description

Schematics are loaded relative to the project first, and if the collection isn't found in the project then it's resolved in the folder the `angular.json` is in. This is great because it allows for situations where multiple versions of a collection are in use, or for collections that require peer dependencies.

The same behaviour is currently not present in architect builders. Those are only resolved in the folder the angular.json file is in, making certain situations impossible.

A very specific case: I've got a repository that contains tooling, and I'm using typescript 4.2 for this repo. I'm using the angular CLI to configure the projects in the repo, with a homebrew architect builder to create npm packages to run in node.
Now I want to add an angular application to the repo to test packages in the repo, as the tool in question is `@ngx-playwright/jest`, meant for using Jest and Playwright to run e2e tests.
However, building the angular app only works if I install `@angular-devkit/build-angular` in the root package.json file, which requires `@angular/compiler-cli`, `@angular/compiler`, `@angular/core`, `rxjs` and `zone.js` as well. It also requires `typscript@>= 4.0 < 4.2` which clashes with the 4.2.3 that I'm using throughout the repo.

Note: I'm using a package manager that doesn't hoist dependencies (i.e. the behaviour of yarn 2's pnp linker or pnpm)

### Describe the solution you'd like

I'd like to be able to install `@angular-devkit/build-angular` in the test application's folder instead of the repo root. This package.json already contains all necessary peer dependencies and it can use 4.1 without me having to downgrade typescript throughout the entire repo.

### Describe alternatives you've considered

- Use a package manager that hoists dependencies. This allows for installing the `@angular-devkit/build-angular` package in the test app's folder while it'll still end up in the root `node_modules` so the angular CLI can find it. It will still find the wrong version of typescript though, so I'm still stuck.
- Downgrade my repo to typescript 4.1: this might be possible, but it feels very wrong that the one angular app in the repo should define the typescript version being used to build the node packages throughout the entire repo as well as the typescript language server version used by VS Code.
- Create a separate `angular.json` in the test app's folder. This is the solution I'm going for, but if I have multiple `angular.json` files I'm losing a lot of the ergonomics the angular CLI normally offers.

Guide de contribution

Ouvrir le guide de contribution

Piste de recherche

Commencez par retracer la manière dont les builders d’Architect référencés dans angular.json sont résolus, en comparant ce comportement avec la résolution des schematics relative au projet décrite. Examinez le package.json racine et le package.json de l’application de test, puis vérifiez que build, serve, test, e2e, lint, extract-i18n et run peuvent utiliser les dépendances de builders du projet sans les nécessiter à la racine du dépôt.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
angular, typescript
Domaine
build-system, cli
Type d'issue
Fonctionnalité
Difficulté
4/5
Temps estimé
3-5 jours
Activité
À l'abandon
Clarté
Plutôt claire
Accessibilité débutants
35/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.