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!)

[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.

[facelessuser]

I guess you were maybe asking about API, not UI. I assume you could acquire status from the action rest API: https://docs.github.com/rest/actions. I haven't looked through all of that though.

[LeaVerou]

Yes :) The reason I was asking was that I wondered how feasible it would be to write an app that tells us who broke lint — maybe that will be motivating enough without having to enforce it? :grin: Just an idea.

[facelessuser]

I guess my real goal was just to get a feel for how lint is viewed in the project, which I feel I understand now. It's nice to have it passing, but not required.

To be honest, I don't specifically care if it is "enforced", I was probably more just looking for a discussion on understanding expected work flow habits from everyone if we find value in lint. And answer questions like do I bother bringing up lint issues in reviews, do I not bother, etc?

I guess I'll just decide how to approach things as I encounter them in my PRs. I'll either filter out unrelated changes, muddy the review with unrelated lint fixes, or just ignore lint issue depending on the situation.

I feel with typing issues, I only care as much as whether I'm the cause of typing issues. JS typing is not an area I'm as knowledgeable in.

[LeaVerou]

I’m thinking we should release an alpha (v0.6.0-alpha.1?) so that people can get their hands on v0.6.0 before we release the actual version.