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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better support ng new use cases
#20351
Comments
|
I would like to add few words here. The "newProjectRoot" option from angular.json is quite confusing when working with workspace. For example in NX monorepo there are two folders - apps and libs. This helps to distinguish applications from libraries and provide better project structure. Alternatives:
D:\Projects\my-workspace\apps or D:\Projects\my-workspace\libs Thanks! |
|
#11101 is also somewhat related. |
|
Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends. Find more details about Angular's feature request process in our documentation. |
|
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage. We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package. You can find more details about the feature request process in our documentation. |
|
This came up again in https://twitter.com/justinfagnani/status/1506778260914335749, it's quite difficult to make a repository with Angular library and a demo application without having to conceptualize it as a monorepo. I made https://github.com/dgp1130/ng-root-lib/ to demonstrate how to make a repository structure with a library at the root and a demo app under |
馃殌 Feature request
/cc @mgechev
Command (mark with an
x)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: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.angular.jsonfile is technically a "workspace", song newtechnically 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 newto decide whether to make a standalone application (ng new --type app), a multi-app workspace (ng new --type workspace, equivalent to today'sng new --create-application=false), or a standalone library (ng new --type library). Note thatng new --type appandng new --type libraryboth 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 likeng new --type empty-workspace.This would be distinguished from
ng generatebecauseng newmakes a new repository whileng generateworks within an existing repository. Arguably we should mergeng newandng generate(maybe inferring from file path context whether a new repository is required).Some of the broader questions we should discuss:
ng newandng generatework together or be merged?Describe alternatives you've considered
Apparently you can use
ng-packagrto 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/1373373386802479105The text was updated successfully, but these errors were encountered: