Work in progress

• [x] Install & Setup initial typescript configuration.
• [x] Move over .js files to .ts files as is w/ passing specs and minimal changes.
• [x] Update bin/solidarity to point at the new dist directory.

Local setup should just include npm install -g typescript

TypeError: Cannot read property '1' of null
    at module.exports (/Users/sid/Dev/mobile-app/node_modules/solidarity-react-native/extensions/helpers/getAndroidEnvData.js:13:93)
    at Object.check (/Users/sid/Dev/mobile-app/node_modules/solidarity-react-native/extensions/react-native.js:28:15)
    at Object.<anonymous> (/Users/sid/Dev/mobile-app/node_modules/solidarity/dist/extensions/functions/checkRequirement.js:124:72)
    at Generator.next (<anonymous>)
    at /Users/sid/Dev/mobile-app/node_modules/solidarity/dist/extensions/functions/checkRequirement.js:7:71
    at new Promise (<anonymous>)
    at __awaiter (/Users/sid/Dev/mobile-app/node_modules/solidarity/dist/extensions/functions/checkRequirement.js:3:12)
    at map (/Users/sid/Dev/mobile-app/node_modules/solidarity/dist/extensions/functions/checkRequirement.js:62:44)
    at _map (/Users/sid/Dev/mobile-app/node_modules/solidarity/node_modules/ramda/src/internal/_map.js:6:19)
    at map (/Users/sid/Dev/mobile-app/node_modules/solidarity/node_modules/ramda/src/map.js:64:14)

(split off #181)

Seemingly starting with v2.0.0, solidarity (for a React Native project) shows:

TypeError: Cannot read property '1' of null

✔︎ Solidarity checks valid
⠧ Verifying Android

And it just spins forever on "Verifying Android."

Interestingly, adding --verbose outputs:

✔ Package JSON - ./package.json file
✔ CocoaPods - ./ios/Pods directory
✔ Watchman - watchman binary
✔ Android - ANDROID_HOME env
TypeError: Cannot read property '1' of null
✔ Yarn - yarn binary
✔ NPM - npm binary
✔ React Native - /usr/local/bin/react-native binary
✔ React Native - /usr/local/bin/react-native binary
✔ Node - node binary
✔ Xcode - xcrun binary
✔ Xcode - xcodebuild binary
✔ CocoaPods - pod binary

✔︎ Solidarity checks valid
✨  Done in 3.20s.

(as the "Done" indicates, it actually finishes in this case, rather than hanging as it does without the --verbose) (note that the absolute path on /usr/local/bin/react-native is just to work around #181, and is not necessary with v2.0.1, but the behavior is otherwise the same btw. 2.0.0 and 2.0.1)

solidarity snapshot does not have this issue.

In case it's relevant (the type error makes me wonder if Solidarity is looking for something that's missing in the snapshot?), the Android section of the snapshot is as follows:

    "Android": [
      {
        "rule": "env",
        "variable": "ANDROID_HOME",
        "error": "The ANDROID_HOME environment variable must be set to your local SDK.  Refer to getting started docs for help."
      },
      {
        "rule": "custom",
        "plugin": "React Native",
        "name": "androidVersion"
      }
    ],

I'm using zsh and can confirm that I have watchman installed. But solidarity reports that watchman is not installed. applesimutils and ANDROID_HOME also reported missing

"Watchman": [
  {
    "rule": "cli",
    "binary": "watchman",
    "error": "Please install watchman on this machine. Refer to the official Watchman installation instructions for additional help.",
    "platform": [
      "darwin",
      "linux"
    ]
  }
],
"Detox": [
  {
    "rule": "cli",
    "binary": "detox"
  },
  {
    "rule": "cli",
    "binary": "applesimutils",
    "error": "Try `brew install --HEAD applesimutils`",
    "platform": "darwin"
  }
],
"Android": [
  {
    "rule": "cli",
    "binary": "emulator"
  },
  {
    "rule": "cli",
    "binary": "android"
  },
  {
    "rule": "env",
    "variable": "ANDROID_HOME",
    "error": "The ANDROID_HOME environment variable must be set to your local SDK.  Refer to getting started docs for help."
  }
],

The following are from the cli:

~/D/D ❯❯❯ which applesimutils
/usr/local/bin/applesimutils
~/D/D ❯❯❯ which watchman
/usr/local/bin/watchman
~/D/D❯❯❯ export
ANDROID_HOME=/Users/.../Library/Android/sdk

Problem

Solidarity is reporting that I have the wrong version of React Native installed.

✖ react-native: you have '21', but the project requires '^2.0.1'

Config

In my .solidarity file I have this:

    "React Native": [
      {
        "rule": "cli",
        "binary": "react-native",
        "semver": "^2.0.1",
        "platform": "darwin"
      }
    ],

System Settings

System
  platform           darwin
  arch               x64
  cpu                8 cores                               Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz

JavaScript
  node               9.5.0        /usr/local/bin/node
  npm                5.6.0        /usr/local/bin/npm
  yarn               1.3.2        /usr/local/bin/yarn

React Native
  react-native-cli   2.0.1
  app rn version     0.53.0

Symptoms

From my shell, if I type react-native --version I get this:

If I type: ./node_modules/.bin/react-native --version I get this:

Path Hijacking

When you exec a command with Node.JS, it prepends several node binary paths in front of anything that is defined in your shell.

That means ./node_modules/.bin/react-native wins over $(which react-native).

Which means our command output gets us:

Scanning folders for symlinks in /Users/steve/src/ir/clients/lanetix/node_modules (21ms)
0.53.0

Instead of

react-native-cli: 2.0.1
react-native: 0.53.0

Which means your regex is picking up the (21ms) part instead of the 0.53.0 part.

Giving you version 21 installed.

Even If It Did Work...

Here's the fun part.

Let's say you put a "line": 2 in your solidarity rule.

Now you get:

✖ react-native: you have '0.53.0', but the project requires '^2.0.1'

It's reporting the react-native dependency and not the react-native-cli.

Effectively, the react-native-cli becomes invisible unless you start mucking about with the env.PATH that exec uses.

react-native-cli vs react-native

react-native-cli is only required to create a project. If you are using .solidarity, you already have your project created... so this rule is kinda redundant if you already have a rule that checks for the presence of the node_modules directory.

I'm just going to delete the rule in my projects.

Having a hard time just setting up this repository locally w/ a passing test suite. It would be nice to have some sort of guidelines i.e: Node versioning and any other requirements.

#Add docsify

• npm run generate:docs to generate docs
• npm run serve:docs to serve locally on localhost:3000 for dev purposes
• More here ->docsify cli

The current published JSON schema does not reflect the latest 2.3.1 build

Most notably, shell and custom definition types are missing.

There is probably a version flag I'm missing, but this is the one that is published in the example

There needs to be clean way to read and understand how to use solidarity. Preferably, I'd love to have something where I write markdown, and it generates the github site.

I'm looking into Docsify but could really use some help on setup for this portion of the app. I'm terribly distracted while I'm working on the internals, so I haven't spent any time finding the best solution.

This extends rules with a fix property and adds a fix option to the solidarity command that allows users to run the specified fix script when a rule fails. Fixes could be anything from installing a binary via brew to opening documentation in a browser.

@GantMan I started working through this but ran out of time. Can you carry the ball forward from here? I've made some progress, but am still getting test failures.

Just rediscovered this project after not using it for a few projects, and I'm a bit sad it doesn't seem to be maintained anymore.

Haven't really found a better alternative. We do have react-native doctor and expo doctor, but it's not very configurable, and I'd love to use something like this for Node/backend projects as well. Is there a more generally used package out there I've missed?

Some would-be-nices if this is still something to build on:

• Validate .nvmrc versions (currently it's not possible to compare cli output to a file, right?)
• Make it possible to use "cli doctor" tools like react-native doctor and expo doctor inside solidarity
• A plugin to warn when Windows line endings is about to cause problems 😄
• A plugin aimed at Expo

Hi, I'm trying to run a shell script to detect if you have nvm or fnm installed.

The first case passes (in both solidarity and shell) if you have fnm install or the .nvm folder exists at your home root.

The second case fails when running solidarity but passes when ran in shell.

To replicate this issue you will need to have nvm installed. https://github.com/nvm-sh/nvm

Example .solidarity json

{
  "$schema": "http://json.schemastore.org/solidaritySchema",
  "requirements": {
    "Node Manager (NVM | FNM)": [
      {
        "rule": "shell",
        "command": "if [ $(command -v fnm) ] || [ -d $HOME/.nvm ]; then echo true; fi;",
        "match": "true",
        "error": "NVM or FNM binaries are not detected"
      },
      {
        "rule": "shell",
        "command": "if [ $(command -v nvm) ]; then echo true; fi;",
        "match": "true",
        "error": "NVM not detected"
      }
    ],
  }
}

I tried the fix command like this: "fix": "brew install node@{{wantedVersion}}" but it doesn't work.

I think having {{installedVersion}} and {{wantedVersion}} available in the fix command would be great.

How does solidarity work for detecting that it is currently running on continuous integration?

Do I need to pass a flag? Example npx solidarity --ci

Also the question Should this rule be skipped on a Continuous Integration server? seems to output a "ci": true when selecting to skip the rule, is this intended or does "ci": true allow the rule to run on ci?

Example

{
  "requirements": [
    {
      "rule": "cli",
      "binary": "",
      "platform": [
        "macos",
        "linux"
      ],
      "ci": true
    }
  ]
}