typegoose VS flow-typed

So we started researching the state-of-the-art and discovered several libraries that could fit our requirements. The best candidates we were able to find were Mongoose, Typegoose, and TypeORM. Mongoose is a well-known Node.js library for MongoDB that implements the Data Mapper pattern and lets developers define schemas to constraint the data models associated with their domain objects. However, Mongoose works with concrete data models, which in a complex domain model scenario results in query logic duplication. Typegoose is a type-safe Mongoose wrapper that allows schema constraint declaration at domain object field level via JS decorators. Unfortunately, those very decorators leak persistence logic into the domain model. Besides, Typegoose also implements the Data Mapper pattern, thus sharing the same drawbacks of Mongoose. TypeORM, on another hand, implements the Repository pattern and provides some basic support for MongoDB. However, TypeORM presents several limitations compared to Mongoose.

This is where Typegoose comes in, which is basically a wrapper to create TypeScript templates in an easy way. I bet that at some point you've already tried TypeORM and most likely liked working with classes and decorators to define the fields of your entities.

There's so many more cool features and utilities with typegoose, such as creating static and instance methods directly inside of the class, that I would advise you to check out at the official docs!

Sry for asking, can't you use https://github.com/typegoose/typegoose for all of the typing?

I found this: https://github.com/typegoose/typegoose but I feel like the API is not very readable.

If your library is written in TypeScript, you can automatically generate both JavaScript code (to support all users) and TypeScript declaration files (which add TypeScript types to JavaScript code). You will almost never need to export TypeScript files in your package, unless all of your users will use TypeScript (i.e. for something like typegoose).

I'm very curious, which "Redux code" are you referring to here?

I don't think the `redux` core lib ever shipped any Flow types itself. Looking at the FlowTyped repo, I see community typedefs at https://github.com/flow-typed/flow-typed/tree/master/definit... , and the Git history suggests those were indeed written by community members.

(of course on the flip side, _I_ didn't even start learning TS myself until 2019, and goodness knows _that_ has been a lot of trial and error over time :) )

As for configurability of whether casts should error, in my experience with flow it's paradoxically riskier to rely on a type nag when refactoring an unknown "offending" type casts. I've ran into cases where upgrading flow raised a cast issue, it got "fixed" it in a way that made the type system happy, but inadvertently broke tests because falsy values are tricky like that. Here's an example where a type nag showed up for someone refactoring, they did what they thought was reasonable to silence it, and proceeded to accidentally break the entire tool (slipping through tests and code review, to boot). This happened in the flow-typed tool of all places.

The process of supporting Flow users is extremely similar to that of TypeScript. Instead of adding the definition file to "types" in package.json, make a .js.flow file alongside every .js file that is being exported (for example, if you export lib/index.js, make sure to create lib/index.js.flow with the definitions). See the docs on how to create such a definition. If you want to support Flow yourself, don't publish to flow-typed; it's mainly meant for community members to create their own types for third-party packages and publish them there.