Skip to content
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

Merged
merged 26 commits into from
Feb 21, 2020
Merged

Conversation

lpedrosa
Copy link
Contributor

@lpedrosa lpedrosa commented Jan 28, 2020

Summary

Started adapting the CLI code so it uses the FakeHelpers.formatFileAsync as mentioned on #642

I have tried to respect the previous functionality, e.g.

  • When the file is unchanged it is still written to the provided 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 below

Let 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:

  • The 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.
type FormatResult =
    | Formatted of file: string * content: string // as opposed to the temp file
    | Unchanged of file: string
    | Error of file:string * Exception

I also have a couple of questions:

  • Have you considered testing the CLI? For example, I have noticed that the --stdin functionality doesn't work with this current version (I'll submit another PR to fix this).
  • Is the CLI output stable, or can it be changed? For example:
    • When the CLI fails to format a file, it prints a massive stack trace. It could be more user friendly instead e.g. error: Failed to format file <x>: <error message>.
    • Unchanged files should probably still be printed to stdout

@lpedrosa lpedrosa requested a review from nojaf January 28, 2020 20:26
src/Fantomas/FakeHelpers.fs Outdated Show resolved Hide resolved
@nojaf
Copy link
Contributor

nojaf commented Jan 29, 2020

Hey @lpedrosa , looking good so far!

I'm ok with changing FormatResult, however, the behaviour of the FAKE helper should stay the same. formatCode should not break.

Maybe mark formatFilesAsync,formatFileAsync and others internal so the public api of FakeHelpers is a bit more clear. You might need an [<assembly:InternalsVisibleToAttribute("Fantomas.Tests")>] for Fantomas.CoreGlobalTool as well.

Have you considered testing the CLI? For example, I have noticed that the --stdin functionality doesn't work with this current version (I'll submit another PR to fix this).

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.

Is the CLI output stable, or can it be changed? For example:
When the CLI fails to format a file, it prints a massive stack trace. It could be more user friendly instead e.g. error: Failed to format file : .
Unchanged files should probably still be printed to stdout

There is room for improvement there, I'm ok with changes to that area.

Unchanged files should probably still be printed to stdout

Yes, indeed.

@lpedrosa
Copy link
Contributor Author

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 --stdin functionality.

@nojaf
Copy link
Contributor

nojaf commented Jan 29, 2020

With regards to changing the tool output, do you want this as a separate PR, since it will affect the release version number?

It is ok to include in this PR.
To me, this is more of improvement rather than a breaking change. The next version would be 3.2 so that would cover this feature. Might be somewhat debatable but you shouldn't worry about that.

I've submitted another PR (#656) that fixes the --stdin functionality.

Thanks!

Lastly, could you also update the documentation of the CLI?

@nojaf
Copy link
Contributor

nojaf commented Feb 4, 2020

Hello @lpedrosa , do you need any assistance to finish this PR?

@lpedrosa
Copy link
Contributor Author

lpedrosa commented Feb 4, 2020

I should be able to wrap this up today, thanks!

nojaf and others added 4 commits February 4, 2020 11:28
* 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
@lpedrosa
Copy link
Contributor Author

lpedrosa commented Feb 4, 2020

I have included the --check functionality in the CLI and have also updated the docs.

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
Copy link
Contributor

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.

Copy link
Contributor Author

@lpedrosa lpedrosa Feb 4, 2020

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.

Copy link
Contributor

@nojaf nojaf Feb 4, 2020

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.

@nojaf
Copy link
Contributor

nojaf commented Feb 4, 2020

I released 3.2 yesterday actually.
The proposal is to release a first 3.3 beta once this PR is merged. That way you don't really have to wait that long to use --check. And we can gather some feedback before marking the API as stable.

If you are up for it I would prefer to clean up and write tests in this PR.

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.

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!

@lpedrosa
Copy link
Contributor Author

lpedrosa commented Feb 4, 2020

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
@lpedrosa
Copy link
Contributor Author

lpedrosa commented Feb 7, 2020

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"

@lpedrosa
Copy link
Contributor Author

lpedrosa commented Feb 7, 2020

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 processX functions and friends. That will probably be very involved, and another PR will be easier to review.

Copy link
Contributor

@nojaf nojaf left a 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.

fantomas.sln Outdated Show resolved Hide resolved
src/Fantomas.CoreGlobalTool.Tests/Program.fs Outdated Show resolved Hide resolved
src/Fantomas.CoreGlobalTool/Check.fs Outdated Show resolved Hide resolved
src/Fantomas.CoreGlobalTool.Tests/CheckTests.fs Outdated Show resolved Hide resolved
src/Fantomas.CoreGlobalTool.Tests/CheckTests.fs Outdated Show resolved Hide resolved
@nojaf
Copy link
Contributor

nojaf commented Feb 14, 2020

Hey @lpedrosa, I've found some time to tackle some of the remarks I had.
Could you take a look at these latest changes I've made?

For the most part, I moved some things around so that the same functionality can be easily exposed via FAKEHelpers module.
The main idea is that the caller of the code can decide what they do with the result.
In case the CLI is the caller, I've processed the output as you did.

I hope you don't mind me tinkering with your PR, let me know what you think.

@lpedrosa
Copy link
Contributor Author

Hey @nojaf, I've been away this week. I'll have a look at these changes hopefully on Monday.

I hope you don't mind me tinkering with your PR, let me know what you think

Feel free to thinker away :)

@nojaf nojaf self-requested a review February 21, 2020 13:43
@nojaf
Copy link
Contributor

nojaf commented Feb 21, 2020

Ok, I think we can merge this now.
Unless you think otherwise @lpedrosa?

@lpedrosa
Copy link
Contributor Author

Looks good to me! 🚀

@nojaf nojaf merged commit dfef3d5 into fsprojects:master Feb 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants