-
-
Notifications
You must be signed in to change notification settings - Fork 194
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
Check code after format #655
Conversation
Hey @lpedrosa , looking good so far! I'm ok with changing Maybe mark
No, I've never really considered this. But if there is an easy way (that can run in CI), by all means, go for it.
There is room for improvement there, I'm ok with changes to that area.
Yes, indeed. |
Thanks for the review @nojaf. I will focus on wrapping up this PR, by eliminating the need for the temp files and adding the check functionality along with some tests for that. With regards to changing the tool output, do you want this as a separate PR, since it will affect the release version number? The CLI tests are something I would like to look into, but probably not in this PR. I've submitted another PR (#656) that fixes the |
It is ok to include in this PR.
Thanks! Lastly, could you also update the documentation of the CLI? |
* Uses FakeHelper's format family functions which classify the format result i.e. changed/unchanged/error, in preparation for a --check command (fsprojects#642)
47e3163
to
4e4c513
Compare
Hello @lpedrosa , do you need any assistance to finish this PR? |
I should be able to wrap this up today, thanks! |
* Supports checking both files and folders * Always reports changes to stdout
* previously it was blocking for every element of the sequence and that was delaying the output massivelly * now it should be pretty responsive
I have included the The code can be cleaned up a bit e.g. move the check functionality to a separate module, test it, etc. I can do that afterwards, considering that you might want to release 3.2.x and I don't want to hold the release for that. With regards to testing CLI modules or code, would you prefer another test project, or should I just reference the CLI project in the current test project. |
|> Seq.exists isError | ||
|
||
if hasErrors then | ||
return 99 |
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.
Any particular reason you went with 99? Just wondering though.
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.
Ahah. Not really. We could go with your lucky number. For example black (the python formatter) chose 123.
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 was secretly hoping it was a Jay-Z reference 😋
@jindraivanek do you have a lucky number? I'm ok with 99 or anything else that makes sense.
I released 3.2 yesterday actually. If you are up for it I would prefer to clean up and write tests in this PR.
I would go with a separate project. Keep using NUnit is that is possible. That makes the most sense to me. Very happy with the progress you've made! Big up! |
Thanks for the positive feedback @nojaf. I'm really enjoying helping out and getting my hands dirty with F#. I will clean this up and add some tests then. |
* Added CoreGlobalTool.Test project * Test specific CoreGlobalTool functionality * Separated --check command logic into a separate module
I have added a test project for the CLI functionality. I have also refactored main logic of the check command to a separate module and tested that. I'm just missing the check that @nojaf highlighted above where "if there are no changes and the output file is the same, it shouldn't write anything at all" |
Actually, I suggest we merge this PR in. I have an idea how to tackle the above and it will require refactoring some of the |
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.
Overall very nice work @lpedrosa !
If some minor things could be moved around we can merge this in.
Hey @lpedrosa, I've found some time to tackle some of the remarks I had. For the most part, I moved some things around so that the same functionality can be easily exposed via FAKEHelpers module. I hope you don't mind me tinkering with your PR, let me know what you think. |
Hey @nojaf, I've been away this week. I'll have a look at these changes hopefully on Monday.
Feel free to thinker away :) |
Ok, I think we can merge this now. |
Looks good to me! 🚀 |
Summary
Started adapting the CLI code so it uses the
FakeHelpers.formatFileAsync
as mentioned on #642I have tried to respect the previous functionality, e.g.
TextWriter
A good side-effect of this changes is that we can now identify is a file is unchanged and opt not to do anything.
I haven't yet included the
--check
flag, please see the Notes section belowLet me know what you think @nojaf.
Notes
I also took some time to look through the project and gather some knowledge about the internals. Given that, I wrote down a couple of suggestions that require a discussion before I start slicing through the code:
formatFileAsync
returns a DU which may create or not temp files in the background. I was wondering if it could just return the modified content string instead. Callers can then decide what to do with it, rather than having to read the modified contents from the temp file.I also have a couple of questions:
--stdin
functionality doesn't work with this current version (I'll submit another PR to fix this).error: Failed to format file <x>: <error message>
.