Travis Parsing

[Shard]

Is there a way for me to run style guide portion of the Travis parsing locally? That seems to give me more fits for PRs so far than errors.

Thanks.

[julian]

Sure thing, you can run npm run lint, or ./node_modules/.bin/eslint ., both trigger an eslint run.

Or you could be even more proactive and set up this git pre-commit hook:

#!/bin/bash

for file in $(git diff --cached --name-only | grep -E '\.(js|jsx)$')
do
  git show ":$file" | node_modules/.bin/eslint --stdin --stdin-filename "$file" # we only want to lint the staged changes, not any un-staged changes
  if [ $? -ne 0 ]; then
    echo "ESLint failed on staged file '$file'. Please check your code and try again. You can run ESLint manually via npm run eslint."
    exit 1 # exit with failure status
  fi
done

Then every time you git commit, it'll check for style issues

The first two options check the entire codebase, so that might take awhile. The pre-commit hook only checks staged files so it is much faster, too.

[Shard]

Totally running with the hook. Maybe put that in the dev guide?

[Shard]

Made a small tweak based on covering my ignorance.

#!/bin/bash

# Make sure eslint and related are installed. If not, install it.
if [ ! -f node_modules/.bin/eslint ]; then
  echo "eslint not installed. Installing airbnb-base eslint config, eslint, and related depends."
  (
    export PKG=eslint-config-airbnb-base;
    npm info "$PKG@latest" peerDependencies --json | command sed 's/[\{\},]//g ; s/: /@/g' | xargs npm install --save-dev "$PKG@latest"
  )
  npm install eslint
fi

for file in $(git diff --cached --name-only | grep -E '\.(js|jsx)$')
do
  git show ":$file" | node_modules/.bin/eslint --stdin --stdin-filename "$file" # we only want to lint the staged changes, not any un-staged changes
  if [ $? -ne 0 ]; then
    echo "ESLint failed on staged file '$file'. Please check your code and try again. You can run ESLint manually via npm run eslint."
    exit 1 # exit with failure status
  fi
done

[Shard]

On a related note, is there a way to easily? rig up my fork to the test flow on my fork so that I don't create so much debris trying to solve for coverage?

[PitaJ]

What do you mean by "rig up the test flow"

[Shard]

@pitaj I'd like to run my fork through the same travis/coveralls evaluation that the main repo does without having to clutter up with a messy PR. I make a LOT more mistakes than ya'll still.

[PitaJ]

Oh, well npm test does exactly what travis does, you don't need to worry about coverage. Just add a test for any function you add.