Pluggable CLI templates, add coreapp-cpp project template #10352
Conversation
| @@ -83,14 +83,14 @@ export const windowsInitOptions = initOptions({ | |||
| type: 'string', | |||
| describe: 'The type of project to initialize (supported on 0.64+)', | |||
| choices: ['app', 'lib'], | |||
| default: 'app', | |||
| default: undefined, | |||
There was a problem hiding this comment.
I think for back-compat and test validation, it makes more sense here to leave this value as set, and update the description to include the range of versions, like supported on 0.64-0.70 or whatever.
| type: 'string', | ||
| describe: '[Experimental] Specify a project template to use', | ||
| hidden: true, | ||
| default: undefined, |
There was a problem hiding this comment.
This has to be undefined because it has a conflicts field, but we should comment that here.
| }, | ||
| experimentalNuGetDependency: { | ||
| type: 'boolean', | ||
| describe: | ||
| '[Experimental] change to start consuming a NuGet containing a pre-built dll version of Microsoft.ReactNative', | ||
| hidden: true, | ||
| default: false, | ||
| default: undefined, |
There was a problem hiding this comment.
IIRC, the args parsing code won't ever actually return undefined at runtime with a type set to 'boolean'. It will just return false. So setting this to undefined here is really misleading for devs, - which is why the tests fail - to stop devs from setting this to undefined.
Setting default to undefined only works for string options.
| template: { | ||
| type: 'string', | ||
| describe: '[Experimental] Specify a project template to use', | ||
| hidden: true, |
There was a problem hiding this comment.
Not necessarily a problem with this PR, but I think having experimental options set with hidden: true makes it hard to get them correct since they don't appear in the help. Honestly I think the [Experimental] warning is enough to tell people to beware.
Description
Today when creating a project from the CLI, we have a bit of a combinatorial matrix of possible options:
It becomes hard to maintain to have to consider all
2^{N-1}combinations.The solution I am proposing is that in addition to the options we have today (which we keep in the init CLI for back-compat), we add a new
--templateparameter. This is a string, that just gets passed down to the RNW CLI package, so each version of the RNW package can support a different set of templates.This enables defining a template manifest
template.jsonthat can override the old options, as well as set any nuget packages, and provide its own set of project files and sources. This decouples us from the {shared, cpp, cs} x {lib, app} model, which we will also need for winappsdk (since the project files are very different from uwp's).Type of Change
Microsoft Reviewers: Open in CodeFlow