Angular-cli: feat: Rename angular.json to workspace.json

Created on 17 Apr 2019  ·  11Comments  ·  Source: angular/angular-cli

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.

Most helpful comment

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.

All 11 comments

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".

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.

@emilio-martinez why not just use webpack?

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

@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)?

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.

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.

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.

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.

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

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._

Was this page helpful?
0 / 5 - 0 ratings