Purty 1.0.0 released

[joneshf]

Time for another weekly release of purty. Been a while, but we’re still chugging along. You can grab the npm package or go directly for the binaries.

Notes from the changelog

1.0.0

Official release

It’s finally here! The 1.0.0 release!

Let’s talk about what 1.0.0 doesn’t mean: purty is now “done,” purty has now become “stable,” purty is now “production ready,” purty generates “nice looking code.”

• purty will probably never be “done.” A project like this is almost never “done.” There will always be some improvement to make, a bug to fix, or a syntax to update. Just as languages continue to evolve, so do do styles of those languages.
• purty will not be stable for quite some time. There are many new features in the future and most of these will alter the way modules are formatted.
• purty has been “production ready” since about the 0.3.0 or 0.4.0 release. There are still bugs, there are still improvements to make for the formatting. But, running purty should not “eat your code”, change the semantics of a module, or break in an otherwise bad way.
• Generating “nice looking code” is entirely subjective. There’s probably a consensus around what most people would consider nice, but there’s no way to put a stamp on things and say purty generates “nice looking code.”

1.0.0 is only the beginning. purty does enough now to be “useful.” It’s no longer a proof of concept, it’s a useful tool. It will still have bugs, they will still get fixed. It will still have improvements.

This version also supports PureScript 0.12.0. It should be backwards compatible with PureScript 0.11.7, but there are no guarantees.

Additions

Changes

• Support where clauses

Deletions

[paf31]

Great work!

As soon as we finish upgrading to 0.12, I intend to use this at work.

I will probably fork purty to format things exactly how we’d like. I’m not sure how you’d feel about PRs for that sort of thing - would you consider adding multiple “modes” like some of the Haskell tools? Or do you think it’d be better to keep different formatting rules in forks?

[thomashoneyman]

I’d thought that was the purpose of the .dhall configuration files.

I’d prefer some access to be able to configure formatting rules (like import formatting, line lengths) rather than work of forked versions that can get out of sync, though of course this is ultimately up to @joneshf to decide.

[joneshf]

The end game is to have one “interactive” mode. The dynamic and static modes have always been temporary.

I don’t particularly like the idea of forks, and would probably deprecate if someone made a fork. I’ll happily support another way to format (make PRs, give npm name, etc), but I won’t be maintaining it. My goal isn’t to be the person writing a formatter, it’s to have a formatter exist somewhere in the ecosystem. I’m willing to be that person when nothing exists, but I’m not attached to being that person.

Although I think the interactive approach is the best way for software like this, I’d rather there be one formatter and it format code how it wants. I don’t care enough about how it formats the code if I’m not maintaining it.

The config file exists only to make using the tool easier. If there are flags you can pass, you ought to be able to set them in the config file so you don’t have to pass flags every time once you know what you want.