nbdkit VS DefinitelyTyped

This is correct, but doesn't quite explain why. It's because when you accept contributions from a variety of authors, without using a CLA, then your code base ends up with a patchwork of copyright, making relicensing practically impossible as you have to get buy-in from every author or else determine that author's contributions and remove/rewrite them.

GPL/LGPL are excellent licenses, but this patchwork of copyright can apply for any license you use. For a small project we wrote which was under BSD, we recently had to make a small (non-functional) change to the license, and we got buy-in from all the authors to do this which took quite a long time: https://gitlab.com/nbdkit/nbdkit/-/commit/952ffe0fc7685ea775...

That second link is wrong, should be: https://gitlab.com/nbdkit/nbdkit/-/commit/a956e2e75d6c88eeef...

I think an exception might be made for a plain "C-like" struct that doesn't initialize members or contain anything except basic types. In the specific example[0] the code is actually surrounded by extern "C" { ... } so I suppose that the compiler "knows" this is a plain C struct?

[0] https://gitlab.com/nbdkit/nbdkit/-/blob/cd761c9bf770b23f678f...

We relicensed[1] a project which had 10 contributors, and we got every single one of them to do an Acked-by (by email) which took some weeks. That was the advice from our lawyers. Can't imagine the impossible hassle of doing the same for something like Linux.

[1] https://gitlab.com/nbdkit/nbdkit/-/commit/952ffe0fc7685ea775...

Prior to React 18, it used to include an implicit children prop, making it suitable for components expected to have children. For a long time, though, the implicit children prop type has been removed according to React 18's type changes.

Additionally, because TypeScript has a well established and widely used install-base, there are already many different definition files in the wild for supporting non-TypeScript supporting projects. One of the more extensive collections of these typings lives at the DefinitelyTyped repository, which publishes the package's community typings under the package names @types/your-package-name (where your-package-name is the name of the project you're looking for typings of) that you can look for on your package manager.

View on GitHub

Firefox maintain a library for unified extension API https://github.com/mozilla/webextension-polyfill

Their type definition for HAR request isn't exported https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

type NumberOrString = number | string; type Status = "idle" | "loading" | "success" | "failure" // React useState, can receive a value or a function as parameter to serve as initial value. // https://github.com/DefinitelyTyped/DefinitelyTyped/blob/a03856975a17eba524739676affbf70ac4078176/types/react/v17/index.d.ts#L920 function useState(initialState: S | (() => S)): [S, Dispatch>];

The TypeScript pull request was merged, so Sebastian (who helps maintain the React type definitions) exercised new powers in this pull request to the DefinitelyTyped repository for the React type definitions. At the time of writing, this pull request is still open, but once merged and shipped the React community we will feel its benefits.

there is an open issue: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/61616

Relatively infrequently. Normally, if an npm package is popular and doesn’t have its own types, there will be a community provided types declaration file available from https://github.com/DefinitelyTyped/DefinitelyTyped