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

fix: Handle the case when staged-git-files errors properly #267

Merged
merged 1 commit into from Sep 6, 2017
Merged

Conversation

okonet
Copy link
Collaborator

@okonet okonet commented Sep 6, 2017

Since the implementation was already merged in #255, this PR only adds a test. It will trigger semantic-release to actually release the new version.

Closes #264

@codecov
Copy link

codecov bot commented Sep 6, 2017

Codecov Report

Merging #267 into master will increase coverage by 0.61%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #267      +/-   ##
==========================================
+ Coverage    89.5%   90.12%   +0.61%     
==========================================
  Files          10       10              
  Lines         162      162              
  Branches       23       23              
==========================================
+ Hits          145      146       +1     
+ Misses         16       15       -1     
  Partials        1        1
Impacted Files Coverage Δ
src/runAll.js 77.77% <0%> (+3.7%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 18c3d26...cf4ef0f. Read the comment docs.

@sudo-suhas
Copy link
Collaborator

sudo-suhas commented Sep 6, 2017

Having to mock sgf could prove a problem when we want to add tests for all scenarios. This is what I would suggest:

  it('should reject if staged-git-files returns an error', () => {
    expect.assertions(1)
    return runAll(packageJson, getConfig({ gitDir: os.tmpdir() })).catch(err => {
      expect(err.message).toMatch(/fatal: Not a git repository/)
    })
  })

Do you know if there is a reliable way to get a temporary directory? I am using os.tmpdir() but would prefer to get a tmp directory for lint-staged itself.

@okonet
Copy link
Collaborator Author

okonet commented Sep 6, 2017

I like your suggestion although I think we still will need to test for different scenarios and it is easier to do with the mock. Why do you think it's problematic?

BTW what about https://github.com/sindresorhus/os-tmpdir?

@sudo-suhas
Copy link
Collaborator

Why do you think it's problematic?

Take runScript for example. I don't like having to split my tests across files just for mocks. Not entirely sure if that will be relevant for this, just a little bit of intuition.

BTW what about https://github.com/sindresorhus/os-tmpdir?

This is deprecated, and a ponyfill for os.tmpdir()(what I am using already) which Sindre Sorhus recommends for node 4+.

@okonet
Copy link
Collaborator Author

okonet commented Sep 6, 2017

Take runScript for example.
I don't like having to split my tests across files just for mocks.

Can you be more specific?

Not entirely sure if that will be relevant for this, just a little bit of intuition.

Since this is a bug fix for a blocker, I wouldn't spend much time here to make it right. We can always refactor later.

@okonet okonet merged commit a8a585a into master Sep 6, 2017
@okonet okonet deleted the fix-264 branch September 6, 2017 15:26
@sudo-suhas
Copy link
Collaborator

Can you be more specific?

We have 3 files for testing runScript:

  • runScript.spec.js
  • runScript-mock-findBin.spec.js
  • runScript-mock-pMap.spec.js

If jest.doMock was working as expected, we could have these in a single file. And as we observed with the blinking test, there are weird bugs which can be introduced by mocks. So I prefer to keep mocks as the last resort. But you are right of course, we can refactor later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants