Provide explicit control over feature/layer packageId and namespace

[cmf-moreira]

Summary

Controlling the packageId and generated namespaces of feature/layer packages in @criticalmanufacturing/cli is harder than it should be. The output depends on an interaction between several derived variables — ProjectName, Tenant, rootPackageName, the argument to cmf new feature, and the internal --idSegment that the cli computes from them — and the rules are not obvious to users. Small changes to any of those inputs produce surprising outputs (mismatched casings, missing segments, or duplicated segments), and there is no single flag that lets a user say "I want this package to be named exactly X, with namespace Y."

I would like a way to explicitly set packageId and namespace on cmf new feature / cmf new <layer>, without having to reverse-engineer how Tenant + featureName + idSegment combine.

Motivating example

cmf init TimeTracking Cmf.Custom --MESVersion 11.1.7 ...
cmf new feature Common.TimeTracking
cd Features/Common.TimeTracking
cmf new business

To have a naming near to my expectation, I had to setup a Tenant: Common.TimeTracking.

Results in:

• packageId: Cmf.Custom.Common.TimeTracking.Business ✅
• Generated csproj: Cmf.Custom.Common.TimeTracking.Common.TimeTracking.Common.csproj ❌
• Namespace: namespace Cmf.Custom.Common.TimeTracking.Common.TimeTracking.Common ❌

The Common.TimeTracking segment is duplicated in namespaces and csproj names even though the packageId is correct. The duplication comes from cmf init auto-setting Tenant = "Common.TimeTracking" and cmf new feature Common.TimeTracking producing a feature packageId = "Common.TimeTracking", which are then concatenated by the internal --idSegment logic in LayerTemplateCommand.cs as "{Tenant}.{featureName}".

A user who just wants "a feature called Common.TimeTracking with namespace Cmf.Custom.Common.TimeTracking" has to discover this interaction, work backwards from the output, and pick non-obvious combinations of --tenant / feature argument to dodge the collision — or post-process the generated tree.

What I'd like

Add explicit flags that bypass the derivation chain, e.g.:

cmf new feature --packageId Cmf.Custom.Common.TimeTracking
cmf new business  --packageId Cmf.Custom.Common.TimeTracking.Business

The namespaces of the .NET, angular, or other, that are build using packageId.

When those flags are provided they should be used verbatim for the generated cmfpackage.json / csproj names / C# namespaces, and the current tenant/idSegment math should be skipped.

When the flags are not provided, keep today's defaults for backwards compatibility — but then the implicit behavior should at least be documented, and ideally hardened against the kind of duplication shown above.

Version

• @criticalmanufacturing/cli@5.10.7