-
Notifications
You must be signed in to change notification settings - Fork 117
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
Add to node parsing capabilities #54
Conversation
How do I complete the CLA step? |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your changes look like a great addition 👍 I left two small comments but other than that it looks good.
@doodzik I believe I addressed your comments with the new changes and hope to have also appeased the linter. |
Scratch that, my changes were too aggressive that broke that I need to go back and run tests locally. I hope to have another version tomorrow |
lib/packwerk/const_node_inspector.rb
Outdated
end | ||
rescue Node::TypeError | ||
nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to get the approval of @tomstuart because he raised an issue about defensive node parsing on one of my open PRs. From my understanding, this gem's design focuses on doing a good enough job uncovering dependency/privacy violations. In my opinion, defensive node parsing would fall under that because we don't fail if packwerk cannot handle the code. The downside is that we don't learn about parsing issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I totally agree. I would love to rather propose a fix for the parsing errors we are running into, but am not deep enough into packwerk and parser to understand much of what's going on.
I would be happy to pair on this or run non-defensive versions against the codebase I am looking at to give more input into what might be going on...
If I fix the linting error as proposed by the check, all tests fail: https://github.com/Shopify/packwerk/pull/54/checks?check_run_id=1328856280 |
Could you link to the build with the failing tests? the one you link to only has the failing linter. |
Yes - no longer sure what I saw 🤔 must have been a snafu. I will update the PR |
Thank you for the adjustments! This PR is starting to look like a very valuable bugfix. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR is looking good! Once Philips comment is addressed and fix the merge conflict we can ship this PR 🚢
11d8945
to
aa94892
Compare
Thanks, @doodzik - I have addressed all open comments |
looking good! I'm going to test this on our core monolith. |
It's complicated by the fact that packwerk main is currently broken on our monolith. We may want to fix that first before merging this. Sorry for the delay Stephan. |
We fixed the main branch. @shageman , can you rebase? I'll manually test your branch on our monolith afterwards (I would have rebased myself, but there are merge conflicts and I sadly don't have the time to look into them right now) |
… reference even when there are nil nodes in the namespace path
@exterm done. Thanks! |
Ran it on the core monolith without problems. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution Stephan!
What are you trying to accomplish?
In the codebase I am working on I see several errors related to edge cases where the code parsing fails. I am working to make packwerk run.
What approach did you choose and why?
I added a bunch of defensive statements that makes packwerk continue to run even when individual nodes fail to parse.
What should reviewers focus on?
This doesn't seem like a cohesive PR at the moment. Although the tests do pass, how should I break these changes up so merging would be considered?
Type of Change
Checklist