-
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 generates invalid namespace names in idl files when app has - in name #13426
Comments
We should also look at making react-native-windows-init handle expo apps. The steps are relatively minor: Add a separate package.json script for Add a devDependency for: (Exact version to use will depend on RN version) Ensure the ComponentName in MainPage.xaml gets set to something (it ended up blank in my experiements) Create a index.windows.tsx file at the root with something like (use same component name as used in MainPage.xaml: import React from 'react';
import {AppRegistry, Text, View} from 'react-native';
const App = () => {
return (<View><Text style={{color:"red"}}>Hello world</Text></View>);
}
AppRegistry.registerComponent('MyApp', () => App); |
react-native-windows-init is going to be deprecated - does it repro with |
Re-activating this as I think my PR will actually fix it. |
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
Hit this while starting from a default expo app, which is named: my-app.
The text was updated successfully, but these errors were encountered: