Skip to content
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

Closed
shirakaba opened this issue Aug 11, 2024 · 2 comments · Fixed by #13566
Assignees
Labels
Area: CLI Area: Developer Experience bug Developer First Experience Issues that are going to be hit by a new developer as they first try out RNW
Milestone

Comments

@shirakaba
Copy link

shirakaba commented Aug 11, 2024

Problem Description

react-native-windows-init fails when run inside a project whose name (i.e. the "name" field in its package.json) is prefixed by an org. So, while a project name of react-native-app-auth-js is fine, @my-org/react-native-app-auth-js is not:

ENOENT: no such file or directory, mkdir 'C:\Users\jamie\git\my-monorepo\packages\react-native-app-auth-js\windows\@my-org\react-native-app-auth-js'Error: ENOENT: no such file or directory, mkdir 'C:\Users\jamie\git\my-monorepo\packages\react-native-app-auth-js\windows\@my-org\react-native-app-auth-js'
    at Object.mkdirSync (node:fs:1372:26)
    at createDir (C:\Users\jamie\git\my-monorepo\packages\react-native-app-auth-js\node_modules\@react-native-windows\cli\src\generator-common\index.ts:207:8)
    at copyProjectTemplateAndReplace (C:\Users\jamie\git\my-monorepo\packages\react-native-app-auth-js\node_modules\@react-native-windows\cli\src\generator-windows\index.ts:122:12)
    at generateWindows (C:\Users\jamie\git\my-monorepo\packages\react-native-app-auth-js\node_modules\@react-native-windows\cli\src\index.ts:77:38)   
    at Object.reactNativeWindowsInit (C:\Users\jamie\AppData\Local\npm-cache\_npx\966c6a96be6f5a32\node_modules\react-native-windows-init\src\Cli.ts:660:5) {
  errno: -4058,
  code: 'ENOENT',
  syscall: 'mkdir',
  path: 'C:\\Users\\jamie\\git\\my-monorepo\\packages\\react-native-app-auth-js\\windows\\@my-org\\react-native-app-auth-js'
}

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

  1. First, in my monorepo, I made a package.
  2. For the package's package.json, I set "name": "@my-org/react-native-app-auth-js".

Then, I ran this command, and it failed:

npx --yes react-native-windows-init --overwrite --projectType=app --useHermes --experimentalNuGetDependency --language=cpp --namespace=jp.example.ReactNativeAppAuthJs.demo

I found that if I renamed the package from @my-org/react-native-app-auth-js to react-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

npx @react-native-community/cli info

  WARNING: You should run npx react-native@latest to ensure you're always using the most current version of the CLI. NPX has cached version (0.73.9) != current release (0.74.5)
  
info Fetching system and libraries information...
System:
  OS: Windows 11 10.0.22631
  CPU: (4) x64 Apple Silicon
  Memory: 1.47 GB / 7.99 GB
Binaries:
  Node:
    version: 20.15.0
    path: ~\AppData\Local\Volta\tools\image\node\20.15.0\node.EXE
  Yarn:
    version: 1.22.22
    path: ~\AppData\Local\Volta\tools\image\yarn\1.22.22\bin\yarn.CMD
  npm:
    version: 10.7.0
    path: ~\AppData\Local\Volta\tools\image\node\20.15.0\npm.CMD
  Watchman: Not Found
SDKs:
  Android SDK: Not Found
  Windows SDK:
    AllowDevelopmentWithoutDevLicense: Enabled
    AllowAllTrustedApps: Enabled
    Versions:
      - 10.0.19041.0
      - 10.0.22621.0
IDEs:
  Android Studio: Not Found
  Visual Studio:
    - 17.10.35027.167 (Visual Studio Community 2022)
Languages:
  Java: Not Found
  Ruby: Not Found
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.9
    wanted: ~0.73.9
  react-native-windows:
    installed: 0.73.19
    wanted: ~0.73.17
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: false
  newArchEnabled: true
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

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

@shirakaba shirakaba added the bug label Aug 11, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs: Triage 🔍 New issue that needs to be reviewed by the issue management team (label applied by bot) label Aug 11, 2024
@jonthysell jonthysell self-assigned this Aug 12, 2024
@jonthysell jonthysell added Area: CLI Developer First Experience Issues that are going to be hit by a new developer as they first try out RNW Area: Developer Experience labels Aug 12, 2024
@jonthysell jonthysell added this to the 0.75 milestone Aug 12, 2024
@jonthysell jonthysell removed the Needs: Triage 🔍 New issue that needs to be reviewed by the issue management team (label applied by bot) label Aug 12, 2024
@jonthysell
Copy link
Contributor

As react-native-windows-init will be marked as deprecated in 0.75, you can use the new init-windows command which allows you to specify whatever name and/or namespace you want for the native code, rather than strictly relying the value in package.json. There's a lot of tangled up history in what names do/don't work in the old command (as the one string is frankly overused in the templates, for more than just file names) and the rules for that string have also changed over the years.

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 react-native-windows to your project, try using npx react-native init-windows with any of the available "old/" templates, the list of which you can see via a preview the upcoming docs here: https://microsoft.github.io/react-native-windows/docs/next/init-windows-cli.

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.

@shirakaba
Copy link
Author

shirakaba commented Aug 13, 2024

@jonthysell Thank you! Could you point me at the code for the init-windows CLI and the locations of the templates that it references? I've been struggling to find details about it.

EDIT: I guess the templates for init-windows are in react-native-windows/vnext/templates, though I'm not clear where the code for the init-windows CLI is.

jonthysell added a commit that referenced this issue Aug 26, 2024
## 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
jonthysell added a commit to jonthysell/react-native-windows that referenced this issue Aug 26, 2024
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
jonthysell added a commit to jonthysell/react-native-windows that referenced this issue Aug 26, 2024
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
jonthysell added a commit that referenced this issue Aug 27, 2024
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
jonthysell added a commit that referenced this issue Aug 27, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: CLI Area: Developer Experience bug Developer First Experience Issues that are going to be hit by a new developer as they first try out RNW
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants