Lily Skye

This proposal doesn't feel like it fits in with the language; the rules for access feel arbitrary and confusing. In addition, the `#` prefix feels unnecessary. I'd prefer that `private`...

Could you clarify what you're asking? If you want a certain file in a repo to never be formatted by prettier, you can add it to a `.prettierignore` file: https://prettier.io/docs/en/ignore.html#ignoring-files...

Awesome! I ran into a need for this yesterday and finally understood what you meant. I'll add that package

I don't think that's the that's the same as this issue... But it can live here I guess. The main reason I'm going to use the VS Code package though...

This might be worth revisiting now; I think between the `fill` doc primitive and the markdown work, we have what we need. However, I expect there to be *tons* of...

That would probably work, but I have concerns about the UX if the user has to use `prettier-ignore-comment` a lot. prettier-ignore is an escape hatch, so I'd hate it if...

Yeah; `fill` fills the line without respect to raggedness. I actually prefer that to the minimum raggedness algorithm personally (for code comments)- but it's a matter of preference.

I used the [hard-wrap](https://atom.io/packages/hard-wrap) atom package for a long time up until recently when it broke with the latest version of atom. It behaves very similarly to fill.

I have a lot of those kinds of comments for PropTypes.func, too. I agree that trailing comments are a bit different.

@georgecrawford that could break `$FlowFixMe` and `eslint-disable-next-line` comments