v16.5 patch release with unlocked dependency versions strtok3 & token-types

[Borewit]

@sindresorhus can you please create a patch release with unlocked and updated strtok3 and token-type versions?

Proposed patch branch: https://github.com/sindresorhus/file-type/tree/unlock-strtok3-and-token-types

Relevant commit: e5f43a6

Successor of: #473

[sindresorhus]

I'm a little bit concerned that upgrading these risk potentially breaking things and waste time, but if you think it's worth the risk, sure, I can do that.

I also cannot judge whether it's safe as there are no release notes: https://github.com/Borewit/token-types/releases/tag/v4.0.0

[Borewit]

I fixed the release notes.

It's worth the risk, otherwise I would not ask it,
I though we also agreed to finalize Buffer abstraction before migrating to ESM.

Things had been fixed in #466, but the dependent versions these belong to have been overwritten back with frozen older versions. That is already breaking things.

[Borewit]

Why is this taking so long? This is waste of my time.

[sindresorhus]

@Borewit

1. It's only been a single day since you fixed the release notes and this was actionable.
2. I'm on summer vacation. I have almost not been on the computer since we last talked here.
3. This is open source. It's expected that some things can take days (or weeks).
4. You are the one that caused me to have to lock down the dependencies in the first place.
5. I generally have to wait much longer for you.

However, it's done now: https://github.com/sindresorhus/file-type/releases/tag/v16.5.3

[Borewit]

I admire the contribution you to the open source community, I have only respect for that.

I do my best to critical issues and things which block others and things and that nature in a timely manner. I am sorry to hear that it is not experienced that way. But I try to cover your back actually, so the expectations are based on giving and taking while working on this together.

The work I have carried out on the NPM modules has been strongly driven by your requirements. It was quite frustrating to wait for 14 days for bloody small mistake, for which I had fixes in place at the moment I reported it to you. Freezing the version was not part of any of the proposes solutions and not necessary.

Anyway, thanks for making this release @sindresorhus. Sorry for putting pressure on this one during your summer vacation. I feel bad about that.

[sindresorhus]

No hard feelings. I'm just stating the facts from my point of view. I might have missed something in an issue or something. I admit I have been distracted because I had very little time to handle OSS stuff in the past few weeks. I think the main problem here is simply that we haven't communicated clearly enough.

---

It was quite frustrating to wait for 14 days for bloody small mistake

I was not aware until now that locking the dependencies blocked other work for you.

for which I had fixes in place at the moment I reported it to you

When you reported it to me, you did not say you had fixes in place. You just said the current version was breaking stuff and I quickly locked the dependencies to prevent any damage.

Freezing the version was not part of any of the proposes solutions and not necessary.

It was the correct (and common) solution based on the information I had at the time.

---

If there's any important you need me to do, just be clear about it being important and I'll prioritize it. But I get so many issues each day and if the priority is not clear, I might prioritize other things.