defaultProject deprecated and automatically removed after update to 14.. now ng serve doesn't work

Which @angular/* package(s) are relevant/related to the feature request?

No response

Description

I’ve updated some workspace projects to angular 14. They contain mostly a library and an app, sometimes multiple of either.

in angular.json defaultProject is now removed and CLI gives a warning about it.

However spinning up the dev environment is a daily task and ng serve is a nice shorthand to run it. Now I can’t use it anymore (unless I change it back to deprecated state)

This is imo a step backwards. Commands should be simple by default and we can do that by configuration. I don’t understand why you would remove power from the developer like this.

Proposed solution

Put it back like it was / undeprecate it. or defaultServeProject or defaultBuildProject (which for most of our projects is different (lib vs app))

Alternatives considered

alternatives would be custom solutions like makefiles or just using npm run start (which is more typing, not that big of a deal but do it 100x per day and it becomes a big deal)

[Badisi]

I’m also facing some issues with defaultProject being removed but in the context of schematics.

I have built a library (@hug/ngx-schematics-utilities) that ease the use of angular schematics and since ng14 many of the tests are failing due to defaultProject no more being returned through WorkspaceDefinition.extensions['defaultProject'].

When developing a schematic, running ng add does not provide to the schematic any context of which project the command is currently running against, nor provide to the user any way to specify it (ie. there is no ng add schematicName projectName nor ng add schematicName --project projectName available).

The developer is left alone to implement such a --project option inside his schematic to understand where the schematic should be applied. Having the defaultProject property was a safeguard for any developers forgetting to implement such a mechanism and a nice fallback for any users forgetting to specify a project.

[coenmooij]

Not really understanding what is the problem with cd into a directory and run ng serve from the project directory.

It’s more effort. And I never cd around my projects because I want to always be in root to do any commands. Helps me to have a consistent workflow and no surprises/side-effects.

In a monorepo it’s also ambiguously that when running a command like ng build/generate/test you don’t really know which project the command is executed against.

Exactly because of that ambiguity you want this option. Let the project decide what it wants. The opinionated nature of angular is great but we are forcing workflow here instead of shepherding best practices.

Forcing to be verbose in patterns is just adding extra boilerplate of developer time that could be fixed with configuration.

Shouldn’t commands work by default and with flags/options they become more powerful?

I switch a lot between projects and we have some git hooks that we want to run so I always stop the server when I finish a task and get back to the develop branch or onto another issue. I can’t be the only one.

At the very least, ng serve should autodetect the first application in your projects folder or something. Because now, ng serve in root is broken. Like showing a 404 page on a root domain.

Your considerations about which default project to show is exactly where configuration would be an asset. Because you don’t know, you let the workspace decide. I think the commands should definitely behave similarly / as expected, but that doesn’t mean they don’t have their own uniqueness. How about an optional root ‘serve’ or ‘build’ configuration in which you can supply the default project?

So with moving away from ng serve because of the lack of support for configuration, the npm start solution is perhaps the best, but I cannot help feel a little bit disappointed. I think this is a small thing but it speaks to a larger topic, which is not supporting just the majority (which are partly assumptions) but also empowering pro-users to optimize their workflows.