new-module composes a non-existent template name from the target solution and still exits 0

[benmassaoud]

Is there an existing issue for this?

• I have searched the existing issues

Description

abp new-module <name> -t <template> -ts <solution> prefixes the value of -t with the target solution's template instead of the module: prefix. The composed name does not exist, the command prints Unknown template name - and returns 0.

Because the prefix follows the solution, none of the four documented -t values is reachable once -ts is passed:

Target solution	-t passed	Composed template	Result
app-nolayers-modern	ddd	app-nolayers:ddd	Unknown template name
app-nolayers-modern	standard	app-nolayers:standard	Unknown template name
app-nolayers-modern	standard --modern	app-nolayers:standard-modern	Unknown template name
app-modern	standard --modern	app:standard-modern	Unknown template name
app-nolayers-modern	(none)	module:ddd	module is produced
app-nolayers-modern	module:standard-modern	as-is	module is produced

The fourth row is what makes this a framework-wide issue rather than a quirk of one template family: a layered solution composes app:standard-modern, equally non-existent.

The valid names are the ones the CLI enumerates itself:

abp list-templates    # module:ddd, module:standard, module:ddd-modern, module:standard-modern

Why exit code 0 matters. It makes the failure invisible to any script: a CI pipeline that creates a module carries on as if nothing happened, and the absence only surfaces at the next step. And the documented value of an option cannot be passed to that option.

A second defect in the same command. -ts requires an absolute path. A relative value throws before any template is read:

Unhandled exception. System.ArgumentException: Basepath argument is not fully qualified. (Parameter 'basePath')
   at Volo.Abp.Studio.Solutions.SolutionInfoLoader.LoadAsync(String path)
   at Volo.Abp.Studio.Cli.Commands.NewModuleCommand.ExecuteAsync(CommandLineArgs commandLineArgs)

The message names neither the option at fault nor the offending path. This one exits 127, so the two defects of the same command do not even share an exit code.

What is asked:

1. compose module:<template> whatever the target solution's template is;
2. return a non-zero exit code when the template cannot be found;
3. accept a relative -ts, or name the option in the error message.

Reproduction Steps

cd <an app-nolayers-modern solution>
abp list-templates                                                          # module:* are the valid names
abp new-module ModA -o modules -csf -t standard -ts "$PWD/Probe.abpsln"; echo "exit=$?"
                                                    # Error: Unknown template name: app-nolayers:standard
                                                    # exit=0
abp new-module ModB -o modules -csf              -ts "$PWD/Probe.abpsln"; echo "exit=$?"
                                                    # module produced
abp new-module ModC -o modules -csf -t standard -ts "Probe.abpsln"; echo "exit=$?"
                                                    # ArgumentException, exit=127

Expected - a documented -t value produces the module, and an unknown template exits non-zero.

Actual - the composed name is never a real template, and the failure is reported with exit code 0.

Version

3.0.10 (Volo.Abp.Studio.Cli, the latest published at time of measurement). Behaviour is identical on 3.0.9.

Operation System

Windows (Default)

Solution Configuration

• Template: app-nolayers, and reproduced on app (layered) as well
• Created ABP Studio Version: 3.0.10 CLI
• Tiered: No
• UI Framework: react
• Database Provider: ef
• Public Website: No

Other information

Point 2 is the one that costs the most in practice. Any automation reading the exit code treats a failed module creation as a success, so the missing module is discovered later, somewhere else, by an error that does not name it.

[maliming]

Hi,

All three are covered by the change I prepared. Short template names are resolved against the registered module templates instead of being composed from the target solution, so the documented ddd and standard work with -ts while solution-owned names like gateway and web keep working for microservice solutions. An unknown template returns a non-zero exit code, and a relative -ts is resolved against the current directory.

Your report also surfaced a separate one. A modern solution stores the base name in template and the modern variant in templateType, so looking for a -modern suffix in the template name never picked the modern module automatically - abp new-module Foo in a modern solution produced a classic module. It follows the solution's template type now.

One thing to keep in mind: without --modern, a full name like -t module:ddd stays an explicit classic choice even in a modern solution. Pass -t module:ddd-modern, or combine -t module:ddd with --modern, to get the modern variant.

The changes are under review, they are not part of 3.0.10.

Thanks