@baris He said he uses 1.4.5 and Chrome in Mac OS.He tried to destroy his friend's experimental community,and then my friend's forum throwed an error:(See the image)
0_1492190618361_-219a3516140dd67a.png
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.
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.
Totally running with the hook. Maybe put that in the dev guide?
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 "[email protected]est" peerDependencies --json | command sed 's/[\{\},]//g ; s/: /@/g' | xargs npm install --save-dev "[email protected]"
)
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
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?
What do you mean by "rig up the test flow"
@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.
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.