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

doctor: detect wrong app dependencies #1848

Open
cortinico opened this issue Feb 27, 2023 · 4 comments
Open

doctor: detect wrong app dependencies #1848

cortinico opened this issue Feb 27, 2023 · 4 comments
Labels
command: doctor feature request no-stale-bot This issue cannot be marked as stale by stale bot

Comments

@cortinico
Copy link
Member

Describe the Feature

I'd like to propose a feature for doctor that will ideally make life easier for users when upgrading RN versions: detect erroneous top level package.

Essentially inside the app package.json file in the dependencies/devDependencies block, we should inspect for packages which are known to be incompatible (an alternative could be to inspect the yarn.lock).

Packages you should not have in your app package.json are:

A more relaxed way to check for those depedencies is to verify if they're compatible with the RN version (so for instance react-native 0.71.x works only with react-native-codegen version 0.71.x and so on).

In general, there is no reason why a user should directly depend on a package like react-native/@gradle-plugin. What happens is that users find a (generally wrong) workaround somewhere on Github/StackOverflow, and this dependency ends up in their package.json causing future react-native version upgrades to fail badly.

Related Issues

See here for a build failure generated by wrong codegen version:
facebook/react-native#36286 (comment)

See here for a build failure generated by wrong gradle plugin version:
facebook/react-native#36198 (comment)

@blakef
Copy link
Contributor

blakef commented Mar 20, 2023

@cortinico checking my understanding of this here, we should be:

  • warning users against linking against a specific version of our dependencies in the packages/ folder (excluding react-native)
  • erroring if the version linked doesn't match minor versions?

Reference:

❯ find . -maxdepth 2 -name 'package.json' | xargs -J % jq '. | {name,version}' %
{
  "name": "@react-native/babel-plugin-codegen",
  "version": "0.72.3"
}
{
  "name": "@react-native/bots",
  "version": "0.0.0"
}
{
  "name": "@react-native/codegen",
  "version": "0.72.3"
}
{
  "name": "@react-native/eslint-plugin",
  "version": "0.72.0"
}
{
  "name": "react-native",
  "version": "1000.0.0"
}
{
  "name": "@react-native/normalize-colors",
  "version": "0.72.0"
}
{
  "name": "@react-native/hermes-inspector-msggen",
  "version": "0.72.0"
}
{
  "name": "@react-native/gradle-plugin",
  "version": "0.72.5"
}
{
  "name": "@react-native/eslint-plugin-specs",
  "version": "0.72.2"
}
{
  "name": "@react-native/eslint-config",
  "version": "0.72.1"
}
{
  "name": "@react-native/js-polyfills",
  "version": "0.72.1"
}
{
  "name": "@react-native/virtualized-lists",
  "version": "0.72.2"
}
{
  "name": "@react-native/assets-registry",
  "version": "0.72.0"
}
{
  "name": "@react-native/tester",
  "version": "0.0.1"
}

@cortinico
Copy link
Member Author

  • warning users against linking against a specific version of our dependencies in the packages/ folder (excluding react-native)
  • erroring if the version linked doesn't match minor versions?

I would start with having both as warnigns. But yes you're correct.

  • If you directly depend on @react-native/codegen, there is probably something wrong with your setup (unless you know what you're doing).
  • If you depend on a version of @react-native/codegen which is misalinged with the react-native minor version, there is definitely somethign wrong going on (things will blow up).
    Still there might be valid scenarios where a user might want to do so, but those are edge cases.

Starting with both warnigns would be the preffered approach for me

@github-actions
Copy link

There hasn't been any activity on this issue in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.

@github-actions
Copy link

There hasn't been any activity on this issue in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.

@github-actions github-actions bot added the stale label Sep 18, 2023
@adamTrz adamTrz added no-stale-bot This issue cannot be marked as stale by stale bot and removed stale labels Sep 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
command: doctor feature request no-stale-bot This issue cannot be marked as stale by stale bot
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants