Closed Scotchester closed 9 years ago
:+1:
Added a commit to fix two problems on the initial run of grunt:eslint
after generation:
First, our latest ESLint file uses a rule that was added in ESLint 0.16.0.
Running "eslint:target" (eslint) task
Warning: Definition for rule 'semi-spacing' was not found. Use --force to continue.
To fix this, I updated the grunt-eslint version number to 11.0.0.
Also, the template's app.js
file threw two line-length warnings, so I edited it to fix that.
On the subject of dependency pinning:
Why are we inconsistent about what gets ~
and what gets ^
? Seems like we should pick a position and stick to it.
Personally, I like ~
because I feel like, for the most part, we can trust package authors to not break compatibility with patch-level releases. But @contolini made an argument for hard pinning the other day.
Should I make this an issue in cfpb/front-end?
our latest ESLint file uses a rule that was added (renamed?) in ESLint 0.19.0.
semi-spacing
was added in 0.18.0., there are additional rules added in 0.19.0. that we'll want to include in https://github.com/cfpb/front-end/blob/master/.eslintrc
Actually, it was 0.16.0. I misunderstood the Git tag display at the top of this commit: https://github.com/eslint/eslint/commit/151bc5021475af44b053e1a38e908c34858f9060
But yeah, you're right about updating with the new rules.
I don't think I made an argument for hard-pinning. I think I said if you feel you need hard-pinning, use npm shrinkwrap to create a shrinkwrap file.
The mix of tildes and carets is because npm started defaulting to carets last year.
Nice work @Scotchester :+1:
@contolini Fair enough, but do we agree that we should pick one or the other and standardize on it?
@Scotchester It doesn't really bug me but it looks like you can change the default if the team wants to standardize on something. I lean toward the caret because a) it's what the larger community uses and b) there's nothing wrong with getting new API-compatible functionality provided by minor releases (assuming, of course, the author has used semver correctly).
Oh and before you squash this, have the test check for .eslintrc
by adding it to the end of this array.
I did, upon fuller reading of that article note that the caret works in the same way as the tilde for 0.x.x
releases, which makes me feel better about it.
I'm in favor of standardizing on the caret. Other opinions?
Re: checking for .eslintrc
. How do I run the tests?
npm test
from the project root. I'll add some testing notes to the readme.
It's testing the state of my local repo, right? The first line of the output is
> generator-cf@0.5.0 test /Users/cranfills/Projects/Capital Framework/generator-cf
Yeah, that looks correct. You can double check the test is working correctly by adding a fake filename to that array and the test should fail.
:+1: Tests pass.
This PR:
osLibraries
array at the top ofindex.js
Sets up the
downloadTemplate
function to consume that array and fetch the contents of each of its included URLS before moving on to theappFiles
function.This enables us to add more source repos in the future, if needed.
.eslintrc
file from thefront-end
repo cache to the new project..eslintrc
template file.Review:
Closes #58