Preparing for v0.6.0

[LeaVerou]

Just started a draft for the release notes, and opening this issue for any discussion on things that need to happen before v0.6.0.

I think the main blocker right now is porting the types to JSDoc and making sure everything works correctly (thanks so much @MysteryBlokHed for working on this!)

---

Edit: This thread is for Color.js collaborators to coordinate the new release. If you have found a bug that you feel should block the new release, please create a new issue and we will assign a suitable milestone. Thank you! 🙏🏼

[facelessuser]

I would like to request that we have all lint issues fixed before release or turn off lint checking.

If we want to have lint turned on, I'd like to see it be mandatory that commits don't break it. If not, lint becomes meaningless and I'm likely to ignore it. If we don't want to enforce lint, it should be turned off as it just becomes noise.

[LeaVerou]

I would like to request that we have all lint issues fixed before release or turn off lint checking.

npm run lint is currently producing a ton of dtslint errors, which we plan to fix once #528 is merged. And yes, we wouldn't make a new release with lint errors.

If we want to have lint turned on, I'd like to see it be mandatory that commits don't break it. If not, lint becomes meaningless and I'm likely to ignore it. If we don't want to enforce lint, it should be turned off as it just becomes noise.

I think it's useful to have in CI, but rejecting commits on the basis of linting seems unnecessarily draconian. I wonder if we can just reduce the noise, e.g. not have emails sent every time a commit breaks linting. For me that’s what’s adding noise, having a red indicator in a PR is useful without adding noise.

[LeaVerou]

I was also thinking it’s about time to try and make Color.js financially sustainable. I think Open Collective seems best suited to geographically diverse teams. I started a Collective so we can experiment: https://opencollective.com/color

No idea what tiers etc to include but we can brainstorm that together.

I'm also not sure how to allocate the funds, but we can cross that bridge once we actually have any non-negligible funds worth allocating :P

[facelessuser]

I think it's useful to have in CI, but rejecting commits on the basis of linting seems unnecessarily draconian. I wonder if we can just reduce the noise, e.g. not have emails sent every time a commit breaks linting. For me that’s what’s adding noise, having a red indicator in a PR is useful without adding noise.

For me, if lint is desired, it helps to have it required because it means I can make sure my specific changes aren't breaking lint. When it isn't enforced, then I have to sort through everyone's lint because I don't want to commit unrelated changes to my PR. After a while, if not enforced, it becomes a hassle, and then I just want to ignore them all. I'm fine with whatever choice you wish, I just wanted to express how it affects me as a developer. If not enforced, I figure why bother if no one else cares.

[LeaVerou]

Gotcha. Has this been an issue until we started having a ton of lint issues due to the recent breakage in tooling? I’m hoping we can manage to mostly avoid lint errors once our tooling is fixed without having to enforce it like that.

[facelessuser]

I think since being enabled, it has rarely been passing. Often I think it gets broken due to direct commits. At least in reviews it can be spotted, but once it is already broken, you have to sort through the broken stuff to address only your own or muddy your review with irrelevant changes. And I think once broken, people start ignoring the status in reviews because they know it is already broken.

Again, this is not a huge deal, just a mild annoyance, and maybe it only annoys me. I guess, in general, I was just trying to get a feel of how much everyone cares or does not care about lint so I can judge how much I should care 🙃.

[LeaVerou]

I have some ideas.

• Q: Is there any tool that will submit an automatic PR with lint fixes?
• Q: Does GitHub expose lint status (passing/failing) anywhere on its API?

[facelessuser]

Q: Does GitHub expose lint status (passing/failing) anywhere on its API?

Yes, you can see a red x on any commit that was failing due to CI, which includes lint. Mobile often hides this, but on desktops it is visible.

Q: Is there any tool that will submit an automatic PR with lint fixes?

You can setup a pre-commit hook to run eslint when pushing if desired. That seems like a more practical approach.