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

[coenmooij]

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)

[alan-agius4]

Hi @coenmooij,

There are a two main ways to choose which project to use;

• change the cwd to the directory (cd) where the project you want to serve is
• use command line argument, example: ng serve my-project

Also the project name can autocompletion in the terminal by pressing tab, if autocompletion is supported and setup.

I am going to mark this for further discussion with the rest of the team and discuss this a bit further.

[coenmooij]

Hi @alan-agius4 ,
changing directory is not really an option for me. I can understand there are groups of devs that use subdirectories but also groups of devs that just use the project from the root. Especially when you use Webstorm and open a terminal in the project. So for that group its not really useful.

As for the longer typed version, that is more effort. Mainly I just don't see a reason to remove it, doesn't seem to be in the way? Or am I missing something? In the end, I feel a cli is a layer that translates the users command into action, and it should help the user, and make it as easy as possible, right?

[alan-agius4]

changing directory is not really an option for me. I can understand there are groups of devs that use subdirectories but also groups of devs that just use the project from the root. Especially when you use Webstorm and open a terminal in the project. So for that group its not really useful.

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

The defaultProject was mostly a legacy option left over from CLI version 1. In fact we there have been discussion to remove this since 2018 as per #11111 (comment)

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.

[dgp1130]

Had some discussion on this and there are a number of options for users to consider to fit their workflow:

1. $ (cd projects/my-project/ && ng serve) - This cd's into the directory and then runs ng serve. It uses a Bash subshell (the parens) to isolated the cd to that subshell, so when the command exits you are still in the original directory. I use this a lot to run commands in specific directory without actually moving my shell, so it's a nice trick if a bit wordly and ugly.
2. $ ng serve my-project - The "cleaner" alternative is to have direct support in the command for running in a different directory / project, and the Angular CLI supports this.
3. $ ng serve <TAB> - If you don't know what projects are available, the CLI can autocomplete it for you as of v14. This can help discover projects in a new Angular workspace you're unfamiliar with.
4. $ npm start - You can set up npm start or any npm run command to do ng serve my-project. This gives a little more control over exactly how you want to structure your workspace.
5. $ alias s="ng serve my-project" - If you really want to micro-optimize typing, you can make an alias which does exactly what you want with whatever name you want to give. I'm sure there's a Windows equivalent but I don't know it offhand.

We briefly considered having ng serve default to serving the only servable project in the workspace (if there is only one such project). This would work for the case of having one or two libraries and a demo application, since only the application can be served. We ultimately decided this was not a good idea because it would diverge ng serve from other commands. ng build can't use the same logic since both libraries and applications are buildable. ng e2e can also get weird in a similar capacity.

We also don't feel that micro-optimizing typing is a real goal of the CLI. Particularly for ng serve, most users run this once and let the project build itself, it's not a command that's run every minute, but rather every few hours (obviously exceptions exist). Also in practice, many users will press Up Arrow x ? -> Enter. Terminals also already have a lot of capabilities for aliases and shortcuts which can do a better job of adapting to user customizations than Angular can.

I do admit that discoverability is a bit of a challenge. Exactly what project names are available is not obvious. ng serve <TAB> is great, but I doubt many devs would think of that as a tool they could leverage. We can likely improve the error message of ng serve in a monorepo to list out available projects and suggest ng serve <project> which can reduce some of the getting started friction for new devs. On a similar point, we can also add some capability to list all available projects in a workspace, which would be a bit more generically useful. Filed #23481 and #23482 to improve those.

Beyond those improvements, our take is that users have enough flexibility in how to control their projects and CLI tools that they shouldn't need defaultProject to get a solid experience.

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

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

[alan-agius4]

I agree that for the ng add we should provide a standard --project option. Related to: #11016

Currently however, providing this option is trivial for schematics author. As all they need to do is to add a project option and add a projectName as a smart default provider. This provider will populate the project option based on the inferred project from the cwd if the option is not provided by the user.

    "project": {
      "type": "string",
      "description": "The name of the project.",
      "$default": {
        "$source": "projectName"
      }
    },

[Badisi]

Thanks @alan-agius4 !

I was not aware of that provider and it surely is a good start to ease the process.
But I would definitely love to see it provided by default in ng add 😉.

[angular-automatic-lock-bot]

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