Better support `ng new` use cases
- 主要语言
- TypeScript
- 星标
- 27k
- 派生
- 11.8k
- 平均合并
- 14 小时 23 分钟
- 30 天内合并 PR
- 162
描述
# 🚀 Feature request
/cc @mgechev
### Command (mark with an `x`)
- [X] new
- [X] generate
### Description
We should rethink some of the DX around `ng new`, as it was originally intended to make new Angular applications, but has expanded somewhat, particularly with monorepos. There are three things in particular which are a bit awkward:
1. There is no way to create an Angular library (using the CLI) without using a monorepo structure. This may not be desired and makes library authorship a little more awkward.
1. To use a monorepo structure, users are supposed to use `ng new --create-application=false`, which is a pretty awkward syntax and doesn't make clear that this is intended for a monorepo/multi-app workspace.
1. Reevaluate the definition of "workspace". I can't speak for others, but I always interpreted a "workspace" as effectively a monorepository for Angular apps. Looking through [docs](https://angular.io/guide/file-structure), it seems that anything with an `angular.json` file is technically a "workspace", so `ng new` technically creates a workspace, even though it isn't a monorepo. I think this definition of "workspace" only really applies internally so we should think more critically about the language here.
Additional context: https://twitter.com/justinfagnani/status/1373336274384293889
### Describe the solution you'd like
I'm thinking we could add an extra flag to `ng new` to decide whether to make a standalone application (`ng new --type app`), a multi-app workspace (`ng new --type workspace`, equivalent to today's `ng new --create-application=false`), or a standalone library (`ng new --type library`). Note that `ng new --type app` and `ng new --type library` both *technically* create a "workspace" per the above definition. We might want to either tweak the definition of "workspace" to mean "a multi-app Angular repo" or use something like `ng new --type empty-workspace`.
This would be distinguished from `ng generate` because `ng new` makes a new repository while `ng generate` works within an existing repository. Arguably we should merge `ng new` and `ng generate` (maybe inferring from file path context whether a new repository is required).
Some of the broader questions we should discuss:
1. How should we position Angular "workspaces"? Are they for monorepositories or not?
2. How should `ng new` and `ng generate` work together or be merged?
### Describe alternatives you've considered
Apparently you can use `ng-packagr` to generate a library without a workspace, but you're losing a lot of the benefits of the CLI by doing so: https://twitter.com/Splaktar/status/1373373386802479105
贡献指南
调研方向
首先审查现有的 `ng new` 和 `ng generate` 行为,以及链接的 Angular 工作区文件结构文档。将当前的 `--create-application=false` 流程与所请求的应用程序、库和多应用程序用例进行比较。在实现之前,必须就工作区术语和命令边界达成一致方向,才算完成。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- angular, typescript
- 领域
- cli, developer-experience
- Issue 类型
- 功能
- 难度
- 5/5
- 预计耗时
- 一周以上
- 活跃度
- 停滞
- 描述清晰度
- 需要澄清
- 新手友好度
- 25/100