It helps ignoring optional type imports in autogenerated type declarations – which is especially useful when one writes #typesInJs.
Ignoring an optional type import makes it silently revert to ”any” when the type can not be imported, which is great when one eg. wants to reference multiple frameworks in the same project without requiring all those types.
Extensive use of inferred types, especially nested complex objects, is bad #typescript / #typesInJs for at least two reasons:
Inferring the types from the implementation rather than making a commitment to a concise and explicit type makes for a needless complex and unclear API-contract – increasing coupling and possible breakage
The state of the nodejs ecosystem is such a mess.. so much build tooling (TypeScript shakes fist), incompatible module systems and multiple package managers each with their own bugs... Building in node used to be so good, alas...
@filmaj@psvensson Though one can ignore most of it and develop like normally. Eg. typescript compilation is not needed for typing, one can go #TypesInJS instead, and eg @fastify is strictly better than old-school Express