Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Rename angular.json to workspace.json #14204

Closed
FrozenPandaz opened this issue Apr 17, 2019 · 11 comments
Closed

feat: Rename angular.json to workspace.json #14204

FrozenPandaz opened this issue Apr 17, 2019 · 11 comments
Assignees

Comments

@FrozenPandaz
Copy link
Contributor

Rename angular.json to workspace.json

Description

The Angular CLI/ Angular Devkit is a generic tool which is extensible to do almost anything. Having the workspace information stored in angular.json is a misnomer as it is possible to have non-Angular projects and builders defined there.

Describe the solution you'd like

With the new Workspace API, storage of the workspace configuration is abstracted. It would be great to support a more agnostic config file such as workspace.json or projects.json.

Currently, folks can already build node apps or web-components apps in an Angular CLI workspace, but the naming of the configuration file deters folks from doing it.

One of the best things about the Angular community is how well we collaborate with other communities. Having the CLI to be more generic and used in those communities will reinforce this.

The angular.json file could be supported for backward compatibility. This would improve the experience for doing things outside of Angular within a workspace.

Describe alternatives you've considered

An alternative could be creating a separate CLI altogether such as the NestJS CLI but it would be great to have 1 agnostic CLI since the Angular CLI is capable of doing both.

@alan-agius4 alan-agius4 added the needs: discussion On the agenda for team meeting to determine next steps label Apr 18, 2019
@mgechev mgechev removed the needs: discussion On the agenda for team meeting to determine next steps label Apr 18, 2019
@mgechev mgechev self-assigned this Apr 18, 2019
@xjose97x
Copy link

I do not like this idea.
If you want to build other type of projects you should probably use webpack (which is used by the Angular CLI 😉).
Angular CLI already has ad-hoc functionality for angular (code generation and scaffolding) that would not make sense in making it "more generic".

@emilio-martinez
Copy link
Contributor

I like the inclusive nature of just calling it "workspace".

The current capabilities of the CLI are already pretty powerful in terms of being able to instantiate projects with custom builders and schematics for things like web component libs or node API development, which I personally only intend to leverage more and more. Anything that goes towards promoting collaboration between concerns has my vote.

@xjose97x
Copy link

@emilio-martinez why not just use webpack?

@jeffbcross
Copy link
Contributor

@xjose97x the CLI itself has been made more generic, the Angular-specific stuff is mostly in builders and schematics now, not the CLI itself.

@xjose97x
Copy link

xjose97x commented Apr 23, 2019

@jeffbcross
The description of Angular CLI is Development tools and libraries *specialized* for Angular.

I do not think that making it more generic helps the project in anyway.

EDIT FOR CLARIFICATION: Why would someone use Angular CLI for non-angular projects when you got Webpack or CLIs specific to it (look Vue CLI, etc)?

@FrozenPandaz
Copy link
Contributor Author

The description of Angular CLI is Development tools and libraries *specialized* for Angular.

I understand your concern that the @angular/cli should be a specialized tool for Angular Development. The Angular CLI is a fantastic tool for Angular Development and that should not change. Under the hood however, Schematics, Architect, and the Workspace API have all been designed agnostic of Angular. Having an agnostic place to store this information opens up those APIs to be used by other tools alongside the Angular CLI. Renaming the configuration file does not detract from this specialization. It instead, opens up the configuration file to be used by other tools such as the @nestjs/cli and others without having to explain why the file is named angular.json.

Why would someone use Angular CLI for non-angular projects when you got Webpack or CLIs specific to it (look Vue CLI, etc)?

Having separate CLIs for each framework exists today and may make sense but it is a separate question. However, storing the information about the workspace in 1 place is important for tools not concerned about which framework a particular project uses. For example, it might be valuable for tools such as GitHub or VSCode to use the information to provide more details about different projects within a repository.

From the perspective of tools, this also provides tools separate from Angular the ability to better integrate with the Angular CLI and other tools simultaneously. For example, tools such as Webpack and Prettier have very little to do with Angular. Using the Angular CLI to invoke Webpack is a great Developer Experience but is specific to the Angular CLI right now. If Webpack were able to create 1 builder which projects of any framework were able to adopt by adding it to their workspace.json file, it would allow such tools to provide a better experience for a wider audience.

@samjulien
Copy link

In this scenario, I would recommend genericizing the entire project (Framework CLI or something), leaving an implementation called Angular CLI with a file still called angular.json -- this prevents breaking changes for tons of people.

@steveblue
Copy link

steveblue commented Apr 26, 2019

Historically the file already changed names and that caused some friction. That friction is alleviated with CLI tooling that allows users to migrate from one to another.

I am extremely happy with the progress that has been made to make the CLI more extensible. I’m not sure that means the CLI can and should be used to build projects outside of Angular. That is most likely beyond the scope of the project. It is possible however.

IMHO you could just latch onto the BuilderContext and give it a way to interpret another config for these use cases where you do want to use the Architect API outside of Angular.

Was the intent of the abstraction to make a tool that can build anything or was the intent to make a tool that can build Angular in several ways (or both)?

I’m wondering if it isn’t the angular.json file to blame for wider adoption for the tools that make the CLI extensible, but instead their package namespaces: @angular-devkit/architect and so on. I recently heard a talk about making “generators” for boilerplate. The speaker was actually talking about schematics. I asked if she ever heard of Angular Schematics and the name alone made it seem like they only work in Angular.

@thekiba
Copy link
Contributor

thekiba commented Apr 27, 2019

And then we can rename everything...
Rename Angular CLI to Workspace CLI
Rename Angular DevKit to Workspace DevKit

And then let's not forget about the most important thing...
Rename Angular to Workspace
Move angular.io to workspace.io

🙅🏼‍♀️

One very important thing. Each tool has its own name in the config name, it makes working with configs easy. So you know for which tool this config is needed.

@mgechev
Copy link
Member

mgechev commented May 1, 2019

After several discussions in the team, we decided to stay with the current workspace configuration file name.

There are three main motivations behind this:

  • We do not want to introduce unnecessary confusion between upgrades of the CLI
  • If we use workspace.json as an alias, we'll have to maintain all the three names .angular.json, angular.json, and workspace.json
  • Having a generic name, such as workspace.json, may introduce an extra unplanned collisions

@mgechev mgechev closed this as completed May 1, 2019
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants