Pino: Bundling pinojs TypeDefinitions with the project and deleting them from DefinitelyTyped

[trivikr]

Hi,

Suggestion from discussion fastify/fastify/issues/649

• TypeScript documentation recommends bundling type definitions with npm package
• Several projects have bundled their typings DefinitelyTyped/DefinitelyTyped/issues/13364
• Example PR which removes babylonjs types from DefinitelyTyped/DefinitelyTyped/pull/15634

I'm wondering if PR would be accepted if pinojs type definitions were moved from DefinitelyTyped to this package

[mcollina]

This team is not maintaining these typings files.
We are not typescript users, so it will be hard for us to maintain them.

If someone wants to join the team and maintain them within this repo, I’d be happy. Otherwise, I’d prefer if we avoid them completely.

[tniessen]

I am using TypeScript a lot, I might be able to help with that if necessary. (I believe the DefinitelyTyped definitions for this project are outdated anyway.)

[trivikr]

Thanks @tniessen
I'm also investigating fastify and pino for my next project, and would also love to help maintain type definitions.

[mcollina]

I’m +1 if you want to send a PR, let’s check with the rest of the team
@jsumners @davidmarkclements what do you think?

[jsumners]

You know my opinion 😉

If someone wants to actually maintain them, fine. I just really wish my editor would quit going to the TS definitions, when they are included, instead of the actual source code when I use the corresponding shortcut.

[trivikr]

Discussion is still going on at fastify/fastify/issues/649
@nwoltman raised some good points about retaining typings in @types/projectname:

• We wouldn't need to worry about updating typings when making changes or when releasing a new version of Fastify since that can be done separately (although this could mean TypeScript users will have to wait for updates to the typings after a new release)
• We'd never need to release a new version of Fastify just to update/fix typings

We can wait to find out results of that discussion before making a decision.

[davidmarkclements]

if @trivikr and @tniessen are both interested in actively maintaining TS definitions then
I'm all for it – I believe in making pino accessible in as many ecosystems as possible when plausible

However, the moment @trivikr and @tniessen stop maintaining them (either officially or they become outdated) and no one else picks up the torch, I would be looking at removing them again

As @mcollina said, we are not TS users (and some might say we're TS averse) – but we'd love to have you guys collaborating from a TS perspective (and if you're interested may invite you to associated modules - e.g. fast-safe-stringify, for TS maintenance)

[trivikr]

@davidmarkclements Sounds good!
Since pino uses pure JavaScript, it would be better to host it's type definitions in DefinitelyTyped (like how it currently is)

I'll sync with @tniessen on how we can update the current type definitions

[trivikr]

After the long discussion in fastify/fastify/issues/649, the team concluded in fastify/fastify/pull/669 to retain the typings within the project.

Would pino maintainers also like to follow the same approach?
Tagging @psnider and @BendingBender who're current maintainers of pino type definitions in DefinitelyTyped

[davidmarkclements]

I'm happy for the same approach 👍

[mcollina]

If there are people willing to maintain it in here, I'm 👍 . Otherwise it can live in @types/pino.

[jsumners]

I abstain.

[psnider]

I wrote the original TypeScript type declarations for pino.
And as a TypeScript user, it is slightly more convenient for me for the type declarations to reside in the project.

But if the maintainers are not working with TypeScript,
then I don't see the value for them maintaining the type declarations,
unless they also serve a documentation purpose.

Although I would be happy to help with maintenance of type declarations within the project,
it is probably easier to get other TypeScript community members to help with the type declarations if they are left in @types/pino.

In any case, the type declarations require some correct and current sample code in order to catch errors in the type declarations. When I worked on the declarations previously, I collaborated with @mcollina to clarify the type declarations, and to select the code for testing the declarations.

[mcollina]

I think we can close this, the types would stay as they are.