-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
react-native-windows-init does not work inside a project whose package name is prefixed by an organisation #13558
Comments
As Anyway, while technically we're "launching" this new command in 0.75, I believe it's already in a working state in 0.73. If you've already added Caution: The new architecture templates available from this command are in no way ready or supported, especially in whatever state they were in in RNW 0.73. |
@jonthysell Thank you! Could you point me at the code for the EDIT: I guess the templates for |
## Description This PR moves all of the logic concerning validating and cleaning project names when creating new projects (via the `init-windows` CLI command or the soon to be deprecated `react-native-windows-init` command) into one shared location with unit tests. It also updates the cleaning logic to handle package scopes (i.e. `@org/package`) and better apply cleaning to packages with hyphens (i.e. `my-package`). Going forward, when creating (new or old arch) projects with `init-windows`, the flow will still to adhere the following rules: 1. Verify that a string specified with `--name` or `--namespace` is valid, or else error out. 2. If an item isn't specified, do our best to determine the value from `package.json`, etc., and clean that value if necessary. When using `react-native-windows-init`, (which still only lets you specify the `--namespace`, and always figures out name from `package.json`, etc.), the flow will be mostly the same as before, where both name and namespace will be cleaned automatically if invalid, rather than erroring out. (However the consolidated cleaning logic should mean an improvement when using tools other than the RN CLI for creating your initial RN project). ### Type of Change - Bug fix (non-breaking change which fixes an issue) ### Why The rules for what constitutes a "valid" name for a RN project has changed over the years with each of the different tools that are used to create RN projects. This PR is an attempt to both broaden the number of supported new project tools while also ensuring RNW still produces usable native code. Closes #13558 Closes #13426 ### What Moved all name(space) logic into a new `nameHelpers` module, exposed them to existing callers, and created unit tests. ## Screenshots N/A ## Testing Add new tests for nameHelpers. ## Changelog Should this change be included in the release notes: _yes_ Improve new project name(space) validation and cleaning
Backport PR microsoft#13566 to 0.75. ## Description This PR moves all of the logic concerning validating and cleaning project names when creating new projects (via the `init-windows` CLI command or the soon to be deprecated `react-native-windows-init` command) into one shared location with unit tests. It also updates the cleaning logic to handle package scopes (i.e. `@org/package`) and better apply cleaning to packages with hyphens (i.e. `my-package`). Going forward, when creating (new or old arch) projects with `init-windows`, the flow will still to adhere the following rules: 1. Verify that a string specified with `--name` or `--namespace` is valid, or else error out. 2. If an item isn't specified, do our best to determine the value from `package.json`, etc., and clean that value if necessary. When using `react-native-windows-init`, (which still only lets you specify the `--namespace`, and always figures out name from `package.json`, etc.), the flow will be mostly the same as before, where both name and namespace will be cleaned automatically if invalid, rather than erroring out. (However the consolidated cleaning logic should mean an improvement when using tools other than the RN CLI for creating your initial RN project). ### Type of Change - Bug fix (non-breaking change which fixes an issue) ### Why The rules for what constitutes a "valid" name for a RN project has changed over the years with each of the different tools that are used to create RN projects. This PR is an attempt to both broaden the number of supported new project tools while also ensuring RNW still produces usable native code. Closes microsoft#13558 Closes microsoft#13426 ### What Moved all name(space) logic into a new `nameHelpers` module, exposed them to existing callers, and created unit tests. ## Screenshots N/A ## Testing Add new tests for nameHelpers. ## Changelog Should this change be included in the release notes: _yes_ [0.75] Improve new project name(space) validation and cleaning
Backport PR microsoft#13566 to 0.74. ## Description This PR moves all of the logic concerning validating and cleaning project names when creating new projects (via the `init-windows` CLI command or the soon to be deprecated `react-native-windows-init` command) into one shared location with unit tests. It also updates the cleaning logic to handle package scopes (i.e. `@org/package`) and better apply cleaning to packages with hyphens (i.e. `my-package`). Going forward, when creating (new or old arch) projects with `init-windows`, the flow will still to adhere the following rules: 1. Verify that a string specified with `--name` or `--namespace` is valid, or else error out. 2. If an item isn't specified, do our best to determine the value from `package.json`, etc., and clean that value if necessary. When using `react-native-windows-init`, (which still only lets you specify the `--namespace`, and always figures out name from `package.json`, etc.), the flow will be mostly the same as before, where both name and namespace will be cleaned automatically if invalid, rather than erroring out. (However the consolidated cleaning logic should mean an improvement when using tools other than the RN CLI for creating your initial RN project). ### Type of Change - Bug fix (non-breaking change which fixes an issue) ### Why The rules for what constitutes a "valid" name for a RN project has changed over the years with each of the different tools that are used to create RN projects. This PR is an attempt to both broaden the number of supported new project tools while also ensuring RNW still produces usable native code. Closes microsoft#13558 Closes microsoft#13426 ### What Moved all name(space) logic into a new `nameHelpers` module, exposed them to existing callers, and created unit tests. ## Screenshots N/A ## Testing Add new tests for nameHelpers. ## Changelog Should this change be included in the release notes: _yes_ [0.74] Improve new project name(space) validation and cleaning
Backport PR #13566 to 0.74. ## Description This PR moves all of the logic concerning validating and cleaning project names when creating new projects (via the `init-windows` CLI command or the soon to be deprecated `react-native-windows-init` command) into one shared location with unit tests. It also updates the cleaning logic to handle package scopes (i.e. `@org/package`) and better apply cleaning to packages with hyphens (i.e. `my-package`). Going forward, when creating (new or old arch) projects with `init-windows`, the flow will still to adhere the following rules: 1. Verify that a string specified with `--name` or `--namespace` is valid, or else error out. 2. If an item isn't specified, do our best to determine the value from `package.json`, etc., and clean that value if necessary. When using `react-native-windows-init`, (which still only lets you specify the `--namespace`, and always figures out name from `package.json`, etc.), the flow will be mostly the same as before, where both name and namespace will be cleaned automatically if invalid, rather than erroring out. (However the consolidated cleaning logic should mean an improvement when using tools other than the RN CLI for creating your initial RN project). ### Type of Change - Bug fix (non-breaking change which fixes an issue) ### Why The rules for what constitutes a "valid" name for a RN project has changed over the years with each of the different tools that are used to create RN projects. This PR is an attempt to both broaden the number of supported new project tools while also ensuring RNW still produces usable native code. Closes #13558 Closes #13426 ### What Moved all name(space) logic into a new `nameHelpers` module, exposed them to existing callers, and created unit tests. ## Screenshots N/A ## Testing Add new tests for nameHelpers. ## Changelog Should this change be included in the release notes: _yes_ [0.74] Improve new project name(space) validation and cleaning
Backport PR #13566 to 0.75. ## Description This PR moves all of the logic concerning validating and cleaning project names when creating new projects (via the `init-windows` CLI command or the soon to be deprecated `react-native-windows-init` command) into one shared location with unit tests. It also updates the cleaning logic to handle package scopes (i.e. `@org/package`) and better apply cleaning to packages with hyphens (i.e. `my-package`). Going forward, when creating (new or old arch) projects with `init-windows`, the flow will still to adhere the following rules: 1. Verify that a string specified with `--name` or `--namespace` is valid, or else error out. 2. If an item isn't specified, do our best to determine the value from `package.json`, etc., and clean that value if necessary. When using `react-native-windows-init`, (which still only lets you specify the `--namespace`, and always figures out name from `package.json`, etc.), the flow will be mostly the same as before, where both name and namespace will be cleaned automatically if invalid, rather than erroring out. (However the consolidated cleaning logic should mean an improvement when using tools other than the RN CLI for creating your initial RN project). ### Type of Change - Bug fix (non-breaking change which fixes an issue) ### Why The rules for what constitutes a "valid" name for a RN project has changed over the years with each of the different tools that are used to create RN projects. This PR is an attempt to both broaden the number of supported new project tools while also ensuring RNW still produces usable native code. Closes #13558 Closes #13426 ### What Moved all name(space) logic into a new `nameHelpers` module, exposed them to existing callers, and created unit tests. ## Screenshots N/A ## Testing Add new tests for nameHelpers. ## Changelog Should this change be included in the release notes: _yes_ [0.75] Improve new project name(space) validation and cleaning
Problem Description
react-native-windows-init
fails when run inside a project whose name (i.e. the "name" field in itspackage.json
) is prefixed by an org. So, while a project name ofreact-native-app-auth-js
is fine,@my-org/react-native-app-auth-js
is not:The reason for failure is that, although it generates a directory named
react-native-app-auth-js
to write boilerplate into, it neglects to generate the parent directory@my-org
.Steps To Reproduce
package.json
, I set"name": "@my-org/react-native-app-auth-js"
.Then, I ran this command, and it failed:
I found that if I renamed the package from
@my-org/react-native-app-auth-js
toreact-native-app-auth-js
, the command ran fine.Expected Results
The CLI should support org prefixes in package names.
CLI version
npx @react-native-community/cli -v
Environment
Community Modules
None
Target Platform Version
None
Target Device(s)
No response
Visual Studio Version
Visual Studio 2022
Build Configuration
None
Snack, code example, screenshot, or link to a repository
No response
The text was updated successfully, but these errors were encountered: