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.

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

[LeaVerou]

Folks, I can't be super on top of this because my PhD thesis defense is in 2 weeks, but it would be good to at least get an alpha out. @MysteryBlokHed should we merge #574? It's still marked as draft.

I wonder if we should post the elaborate release notes with the alpha as well, or only with the actual release?

[svgeesus]

I see a couple of PR are on hold because of linting errors.

An alpha release sounds like a good idea, so we can catch any issues before a full 0.6

[svgeesus]

@MysteryBlokHed should we merge #574? It's still marked as draft.

#574 is merged now.

[jorenbroekema]

You mentioned porting types to JSDocs and making sure everything works correctly

I am on colorjs.io 0.4.5, still using typescript 5.5.2 , everything working fine, but as soon as I upgrade either colorjs.io or typescript to latest, I start getting issues around the following code:

import Color from 'colorjs.io';
const [r, g, b] = new Color('#ff0000').srgb;

When upgrading only colorjs.io to latest I get:
error TS2740: Type 'PlainColorObject' is missing the following properties from type 'Color': spaceId, clone, display, toJSON, and 91 more.

When upgrading only typescript I get 2 errors:
error TS2554: Expected 0 arguments, but got 1.
error TS2339: Property 'srgb' does not exist on type 'Color'.

When upgading BOTH:
error TS2351: This expression is not constructable. Type 'typeof import("/oath/to/node_modules/colorjs.io/types/index")' has no construct signatures.

I'm not sure if these issues are known? I could not find any issues for these yet.

I think in general I've had a lot of typescript related issues with this library in recent releases (some of which were also quite promptly fixed) so I think it's definitely a good idea to double check that things are working as intended with the types for 0.6.0, checking in multiple environments:

• CJS and ESM (assuming you still will support CJS, you have my vote to ditch that)
• browser and NodeJS (maybe Deno/Bun if you want)
• ts-node / tsx runners might also be a good idea, I know a lot of folks use these instead of tsc --watch -> run compiled code from outputDir

[MysteryBlokHed]

When upgrading only colorjs.io to latest I get: error TS2740: Type 'PlainColorObject' is missing the following properties from type 'Color': spaceId, clone, display, toJSON, and 91 more.

When upgrading only typescript I get 2 errors: error TS2554: Expected 0 arguments, but got 1. error TS2339: Property 'srgb' does not exist on type 'Color'.

When upgading BOTH: error TS2351: This expression is not constructable. Type 'typeof import("/oath/to/node_modules/colorjs.io/types/index")' has no construct signatures.

Are there any line+column numbers associated with these errors? That would make it a bit easier to debug what's going on

[jorenbroekema]

import Color from 'colorjs.io';
const [r, g, b] = new Color('#ff0000').srgb;

Given this code snippet, the line number would be line 2. It's a typescript error which doesn't seem to include any further stacktrace or column number for these errors

Btw if these issues aren't known then I can try to create reproduction repos for them and create new issues?

[LeaVerou]

Since writing the changelog was one of the main blockers, I ported the current draft to https://github.com/color-js/color.js/blob/main/releases/v0.6.0.md so we can all collaborate more easily.

I'm thinking, going forwards, every time we make an improvement we could add an entry to the corresponding changelog, so that when the time comes to release, we have it ready, rather than being this monumental effort that needs to happen.

[LeaVerou]

@jorenbroekema could you please post a new issue about this so we can follow up properly? This thread is for collaborators to coordinate about the new release. We can still tag the new issue with a milestone of v0.6.0, but this thread is not for specific bugs. Sorry about that!

[LeaVerou]

Could everyone please review this PR? #607

Assuming this is okay, are there any blockers for releasing an alpha of v0.6.0?

[MysteryBlokHed]

#607 was merged recently. I don’t think there’s anything else that needs to be done before a release, so I think we’re good to go?

[facelessuser]

I think we are ready. People have been poking us about a release long enough.

[lloydk]

I don't think there are any blockers for a release but I would like to see #608 reverted unless there's a good reason for the name change.

[facelessuser]

Ah, I forgot about #608. I think that was merged not realizing a decision on naming had previously been made.

[LeaVerou]

I don't think there are any blockers for a release but I would like to see #608 reverted unless there's a good reason for the name change.

Happy to go with the version the creator uses, which IMO trumps whatever CSS is using (which was not even a consensus decision).

[MysteryBlokHed]

Name was updated in 84efd2b. With that done, I think we're all set for a release?

[svgeesus]

Happy to go with the version the creator uses, which IMO trumps whatever CSS is using (which was not even a consensus decision).

Note that "the version the creator uses" was originally Oklab and CSS Color 4 was changed because we were using OKLab.

I was unaware that the definition of Okhsv and Okhsl (note the capitalization) happened to in passing say OkLCh, which had not previously been defined.

[facelessuser]

Just a note. I just noticed that we decided to go with what the author used, but then we used OKLCh with a uppercase K instead of a lowercase k like the author used...I guess it doesn't really matter at this point, but none of the Ok spaces use an uppercase K when referenced by the author. Figured I'd just clarify if anyone references this and notices the conflict.

[facelessuser]

Never mind, that was over at the CSS docs.

[LeaVerou]

One of my goals for this holiday season is to publish an alpha for 0.6.0. Are there any current blockers?

[MysteryBlokHed]

One of my goals for this holiday season is to publish an alpha for 0.6.0. Are there any current blockers?

Nothing else I can think of. We should be set for a release