-
Notifications
You must be signed in to change notification settings - Fork 17
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
refactor(framework-core): rename modules, functions, & re-org project structure #89
refactor(framework-core): rename modules, functions, & re-org project structure #89
Conversation
Codecov Report
@@ Coverage Diff @@
## comment-pr #89 +/- ##
=============================================
Coverage ? 85.87%
=============================================
Files ? 21
Lines ? 1898
Branches ? 125
=============================================
Hits ? 1630
Misses ? 267
Partials ? 1 Continue to review full report at Codecov.
|
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.
LGTM - I just noticed this was really shifting code around, so no worries on the review feedback. It's ok to address that stuff later (or create a bug to track some cleanup questions)
* @param {string[]} invalidFiles list of invalid files | ||
* @param {Map<string, Range[]>} validFileLines a map of each file's in scope lines for a Pull Request | ||
*/ | ||
export function getValidSuggestionHunks( |
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.
Let's create an interface for the return type instead of the inline definition
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.
Good idea. I'll do that in the next PR for this feature branch.
* Get the in scope (of the corresponding pull request's) hunks and files | ||
* @param {Map<string, RawContent>} rawChanges the raw old content and new content of a file | ||
* @param {string[]} invalidFiles list of invalid files | ||
* @param {Map<string, Range[]>} validFileLines a map of each file's in scope lines for a Pull Request |
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.
Generally, I try to avoid having the types defined both in TypeScript and inlined in the jsdoc like this. The major reason to do it is if we're relying on jsdoc
for technical documentation, which I'd also like to avoid. What's the plan for reference doc generation here? Do we need that?
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.
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.
@JustinBeckwith The intent I've had is more of a stylistic one rather than a reliance. If we remove the jsdoc it will not impact the code clarity to my knowledge since all the parameters have types declared.
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.
These functions are meant to be internal but must be exported for testing (seems like a general issue with typescript visibility). Essentially, we'll only want docs on the 2 entrypoint functions for creating pull requests and reviewing a pull request.
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.
As for the choice of the jsdoc writer, I'm not qualified on the different options 🤷
…n pull requests (#105) * feat(patch text to hunk bounds): support regex for patch texts (#83) * fix(patch text to hunk bounds): support regex for patch texts * more comments and more tests * fix(framework-core): core-library get remote patch ranges (#84) * fix(framework-core): given files old content and new content, compute the valid hunks (#86) * fix(framework-core): parse raw changes to ranges * refactor(framework-core): rename modules, functions, & re-org project structure (#89) * fix(framework-core): hunk to patch object (#91) * feat: build failure message from invalid hunks (#90) * test: add failing stub and test for building the failure message * fix: implement message building * fix: use original line numbers in error message * docs: add docstring * docs: add note about empty input returning empty string * feat(framework-core): comment on prs given suggestions (#93) * feat(framework-core): main interface for create review on a pull request (#114) * feat(framework-core): main interface for create review on a pull request * docs: fix typo * nits and typos... * gts lint warning fix * fix(framework-core): combine review comments (#116) * fix(framework-core): collapsing timeline and inline comments into single review * test: fixed imports * added case when there are out of scope suggestions and no valid suggestions * feat(framework-core): return review number and variable renaming (#117) * feat(framework-core): return review number and variable renaming * lint Co-authored-by: Jeff Ching <chingor@google.com> Co-authored-by: Justin Beckwith <justin.beckwith@gmail.com> Co-authored-by: Benjamin E. Coe <bencoe@google.com>
Because this PR was done in chunks, the initial file structure scaled poorly with an increase of files and different modules. Therefore adding a directory to logically contain modules.
Main functions for that directory are exported by the index.ts files.
Towards #59 🦕