Wrong comments reformatting in `else if` statements

[pcaversaccio]

@Janther @fvictorio I tried the latest update 1.4.0 (can you please make a proper GitHub release with a CHANGELOG?) and the following gets reformatted (see here):

I think this is a bug? If not, please tell me how to configure it outside of the source file so it does not get formatted as I can't change the source file anymore.

[fvictorio]

Thanks for this @pcaversaccio. I think this shows that there are several things we need to improve.

Versioning

In terms of versioning, we do the same that Prettier does. This is not documented anywhere, although there is a very old discussion that sheds some light. Basically: semver doesn't really work for a formatter because you have a (input: string) => string API that can be interpreted as "any change is valid" or "any change is breaking". So in practice:

• Breaking changes to the config are major bumps.
• New options in the config, or significant formatting changes (where "significant" can only be subjective) are minor bumps.
• Fixes (e.g., in the parser) or small formatting changes (again, subjective) are patch bumps.

We should add a section to the Readme explaining this.

Releases

I'm 100% with @pcaversaccio in that we should start having proper GitHub releases that explain what's involved in every new version. IMO this can be done manually, at least for now, since the team is small and we don't publish new releases super often. Alternatively, something like changesets can be very useful. There's also workflows based on conventional commits, but I'm not a fan.

Frozen files

Ethereum projects have something very particular which is that, after deployments and/or audits, some files are effectively frozen. So you very likely don't want to re-format them. I don't have a good answer to this need, but some thoughts in descending order of preference:

• Add those files to .prettierignore. @pcaversaccio told me by DM that the problem with this is that he likes to see the changes in the new version in this file, but I think this is better solved by having proper release notes.
• Use a ~ for the version range of the plugin. This means that already formatted files will most likely not be changed. I don't think this is a complete solution though. There could be a patch bump that changes the file anyway. Besides, you could have other files that continue to evolve, and you might want to have the latest version for those.
• A more advanced system where some files are formatted using older versions of the plugin, and other files use a different version. This seems like a whole project to me, and doesn't seem worth it.