formatting-stack icon indicating copy to clipboard operation
formatting-stack copied to clipboard
verified publisher icon nedap

Eastwood: always use absolute filenames, internally

Open vemv opened this issue 4 years ago • 2 comments

Brief

Part of https://github.com/nedap/formatting-stack/issues/169

As a prerequisite for #169, I found out that filenames coming from Eastwood reports should be absolute, otherwise they wouldn't match with filenames computed by a 'linter caching' mechanism. Of course, a key mismatch means no cache hits.

This is the data path as of master:

  • f-s sends an absolutized filename (via our git strategies) to Eastwood
  • Eastwood may return wither a File (which will be stringed, absolutized) or a string (which will be a relative filename)

This PR proposes making the data path always absolutized filename -> absolutized filename.

QA plan

Verify that Eastwood keeps emitting reports when a fault arises, in vanilla repos and monorepos alike.

⚠️The report should be rendered with relativized filenames (as it's a friendly/concise UI), as always.

Author checklist

  • [ ] I have QAed the functionality
  • [ ] The PR has a reasonably reviewable size and a meaningful commit history
  • [ ] I have run the branch formatter and observed no new/significative warnings
  • [ ] The build passes
  • [ ] I have self-reviewed the PR prior to assignment
  • Additionally, I have code-reviewed iteratively the PR considering the following aspects in isolation:
    • [ ] Correctness
    • [ ] Robustness (red paths, failure handling etc)
    • [ ] Test coverage
    • [ ] Spec coverage
    • [ ] Documentation
    • [ ] Security
    • [ ] Performance
    • [ ] Breaking API changes
    • [ ] Cross-compatibility (Clojure/ClojureScript)

Reviewer checklist

  • [ ] I have checked out this branch and reviewed it locally, running it
  • [ ] I have QAed the functionality
  • [ ] I have reviewed the PR
  • Additionally, I have code-reviewed iteratively the PR considering the following aspects in isolation:
    • [ ] Correctness
    • [ ] Robustness (red paths, failure handling etc)
    • [ ] Test coverage
    • [ ] Spec coverage
    • [ ] Documentation
    • [ ] Security
    • [ ] Performance
    • [ ] Breaking API changes
    • [ ] Cross-compatibility (Clojure/ClojureScript)

vemv avatar Mar 30 '21 01:03 vemv

(This branch has worked well for me in my personal setup. Will undust this PR soon enough)

vemv avatar Sep 03 '21 18:09 vemv

Rebased, gonna give it some extra QAing after this updating

vemv avatar Sep 23 '21 01:09 vemv