Updating for v9

[Ranieri93]

Updating for v9

[jsumners]

I think so.

[jsumners]

Thank you @Ranieri93.

[jsumners]

Do you have in mind a range of dates to inspect data coming from npm-stat.com?

The default is one year to date, and I think that is sufficient. This package shows very limited usage -- https://npm-stat.com/charts.html?package=%40pinojs%2Fjson-colorizer&from=2022-08-27&to=2023-08-27

I also don't see any of the Pino packages depending on this one -- https://www.npmjs.com/package/@pinojs/json-colorizer?activeTab=dependents

From the commit history, it looks like @capaj created this fork and contributed it to the org. I'd like to hear if they remember the reasoning, and if they think it should continue to exist.

I'd also like to hear @mcollina's opinion.

My opinion is that this should be decommissioned (archived in GitHub) and marked as deprecated on npm.

[capaj]

I changed dependency from chalk to colorette because it is faster and then moved the repo to pinojs org.

pinojs/pino-pretty#229 (comment)

if they think it should continue to exist.

I am not sure what you are talking about here. Can you specify?

[jsumners]

I am not sure what you are talking about here. Can you specify?

As shown above, it is not currently used by any Pino project. Given the lack of maintenance of this package, and the lack of usage in other org projects, I think we are better off reducing our burden.

[capaj]

Oh right. Feel free to transfer the package back to me or archive it.
I find it useful and I use it for logging on my development machine on projects I work on daily basis. I would most likely find time to add esm modules and update dependencies.

[Ranieri93]

@jsumners and @capaj thank you so much! Then we'll consider this as deprecated and I'll move to the next one

[jsumners]

@Ranieri93 we haven't heard @mcollina's opinion yet.

[Ranieri93]

Oh, you're entirely correct! Let's hear @mcollina!

[mcollina]

It would be great if we could have colorized output of JavaScript objects in pino-pretty. However a PR to do that never materialized. I think we should ideally do that instead of archiving/transfering.

[jsumners]

Okay, I have created the next branch https://github.com/pinojs/json-colorizer/tree/next

[Ranieri93]

Hey @jsumners, I would like to start working on this.
Now I'll pose some questions, presumably even stupid ones. It's my first time so I'm gonna ask you for some patience. 😄

• Updating dependencies: I assume try to update every package to the latest version and see if tests are still up and running. Do I need anything else?
• Dropping Node <= 16: Here unfortunately I'm in the dark, could you elaborate a little bit?
• Updating CI configuration: I see that here we use Travis and that the config file is pretty straight, so I guess won't be hard. Do I need to pay attention to something in particular?
• Testing suite configuration (tap): Can you elaborate as well? Should I migrate the current framework to tap?
• Anything else you think is required to achieve this is welcome.

Thank you so much in advance!

[jsumners]

• Updating dependencies: I assume try to update every package to the latest version and see if tests are still up and running. Do I need anything else?

No, that should be all. The only catch is to make sure we can actually use the latest versions. Some dependencies have shifted to ESM only, and that won't work. Such dependencies would need to be pinned to the latest version that is non-ESM.

• Dropping Node <= 16: Here unfortunately I'm in the dark, could you elaborate a little bit?

This means removing the CI configuration for any version of Node less than 18. It can also mean going through the code and removing/updating any blocks that specifically tagged as something like "for Node X support".

• Updating CI configuration: I see that here we use Travis and that the config file is pretty straight, so I guess won't be hard. Do I need to pay attention to something in particular?

I would remove Travis and migrate it to GitHub Actions.

• Testing suite configuration (tap): Can you elaborate as well? Should I migrate the current framework to tap?

That would be nice in order to keep thing consistent across the org. But it is definitely not a hard requirement.

[Ranieri93]

Should we consider this as done?