-
Notifications
You must be signed in to change notification settings - Fork 35
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 annotations swallowing comments #72
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
a697ebb
to
c08f6a2
Compare
440607f
to
a8e9b20
Compare
4cba999
to
2b19f5a
Compare
This PR is quite big and a good amount of the lines added are due to test cases I added to document the behavior when annotating a single file. There's a bit of polish left to do in terms of refactors, but I will add that in a future PR. |
drwl
added a commit
that referenced
this pull request
Feb 18, 2024
This PR adds support for other Ruby files types that should be able to get model annotations added to them (i.e. factories, fabricators, etc). In #72, AnnotateRb was changed to use `FileParser::CustomParser` to parse Ruby files instead of relying on regexes. That PR only added support for model files that used either `module Namespace...` or `class ModelName...` as the first line of Ruby. The parser did not have support for other file structures like FactoryBot factories or Fabrication fabricators. There may be other Ruby files that have code that is not currently handled by `CustomParser`, so those will have to be added in the future.
drwl
added a commit
that referenced
this pull request
May 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR attempts to fix a long standing bug that was carried over from the original gem. Comments near an annotation would get removed when adding or updating annotations.
ctran/annotate_models#951, https://github.com/ctran/annotate_models/#warning
Context
Prior to this change, the AnnotateRb and the old gem Annotate would annotate model files in 1 of 2 ways:
:force
option was set to true. A regex would be used to find annotation, remove it from the file, and then add annotations again to the file depending on options such as:position
.Relying on regexes to identify annotations in a file made it hard to reason about and hard to change, so most of them were removed and replaced with a custom Ruby file parser using Ripper [1], which makes working with Ruby files deterministic.
This PR makes the following behavioral changes:
force: false
), it only updates the annotations and should no longer delete any human comments that are before or after an annotation blockforce: true
), it removes the annotation block and surrounding whitespace, if it exists, and then depending on theposition
option, will add annotations before the class declaration or after the class declaration. In the case of re-generating annotations, any surrounding whitespace will be preserved assuming annotations are being written to the same position.[1] A great write up on Ripper: https://kddnewton.com/2022/02/14/formatting-ruby-part-1.html