[feature request] support prettier opt-in for formatting

[semantic-release]

[feature request] support prettier opt-in for formatting

[travi]

I suspect this would be a couple dozen SLOC, though if it needed to generalized beyond prettier it'd pretty quickly get complicated.

yeah, i don't think this project would want to be trying to promote a specific approach, so a generic approach would be a much for us to include it. also, in addition to the effort involved in the initial implementation, i'm concerned that a feature like this would suggest that the generated content is intended to be edited by humans. that could then invite additional requests for handling edge cases around the formatting triggered by semantic-release being resilient to bad formatting introduced by humans, or making a decision for projects around whether we should format the whole file or only the content generated by the current release. as you said, these scenarios can introduce pretty significant complexity for a seemingly simple feature.

oh yeah absolutely - this wasn't intended to be a "help! I'm drowning!" but more of a nice-to-have.

i appreciate the understanding. i think it is unlikely for this to provide enough value to justify the maintenance it could add for maintainers. we do appreciate you opening the issue to help us understand the desire, but we probably need to hear desire from a fairly large portion of our user base to move this forward.

[skeggse]

thank you for your diligent consideration!

[travi]

is it possible to exclude certain files from the linting? in my opinion, applying a lint script to a machine generated file does not provide much value. if it were my project, i would exclude it for the same reasons that i exclude transpiled js files generated with babel from being linted with eslint.

[skeggse]

It is possible, yeah. I could also go that route. Since it's a documentation/markdown file, it feels different from generated code that isn't necessarily intended to be read by a human. I'd prefer to keep all markdown files consistent.

[travi]

intended to be read by a human

i assume that the humans reading this content are reading a rendered version rather than the actual markdown?

i find a lot of value in linting markdown as well, but because editors are very inconsistent and often unforgiving. however, the content that is generated by this tool is not intended to be edited by humans. providing an option to format based on the desires of individual projects could introduce a fairly significant maintenance burden for this tool in order to support an unintended use case.

i can understand this being desirable, but i'm just trying to set the appropriate expectation for this being prioritized.

[skeggse]

i assume that the humans reading this content are reading a rendered version rather than the actual markdown?

🤷 I can't hope to estimate what most people do with markdown files. I know from experience that more than a few just stick to plain-text editors, though I can't imagine it isn't significantly biased by the availability of a nice web UI on GitHub.

providing an option to format based on the desires of individual projects could introduce a fairly significant maintenance burden for this tool in order to support an unintended use case.

I suspect this would be a couple dozen SLOC, though if it needed to generalized beyond prettier it'd pretty quickly get complicated. A totally valid resolution here is "not willing to support."

i can understand this being desirable, but i'm just trying to set the appropriate expectation for this being prioritized.

oh yeah absolutely - this wasn't intended to be a "help! I'm drowning!" but more of a nice-to-have.