monorepo.tools
zod
monorepo.tools | zod | |
---|---|---|
26 | 288 | |
278 | 30,347 | |
1.4% | - | |
2.7 | 9.1 | |
4 months ago | 6 days ago | |
TypeScript | TypeScript | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
monorepo.tools
-
OneRepo: JavaScript/TS monorepo toolchain for safe, strict, fast development
I'm surprised this isn't getting any attention. Reading the docs, sounds very promising, thanks for creating this! I see Nx, Turbo and Moon being mentioned in passing in [Alternatives & pitfalls](https://onerepo.tools/concepts/why-onerepo/#alternatives--pi...), but a more in-depth comparison would be interesting. At least something that could be a column in the table at the bottom of [monorepo.tools](https://monorepo.tools/#tools-review).
-
Josh: Just One Single History
> I don't think anyone coming from a multi-repo world really understands the full implications of a monorepo until they've worked in a large scale one
That's entirely fair. My sole experience is the one black-sheep monorepo at my own relatively-recently joined company, which is nowhere even close to approaching true large scale.
Genuine question, though - what _are_ the advantages, as you see them (you didn't explicitly say as much, but I'm reading between the lines that you _can_ see some)? Every positive claim I've seen (primarily at https://monorepo.tools/, but also elsewhere) feels either flimsy, or outright false:
* "No overhead to create new projects - Use the existing CI setup" - I'm pretty confident that the amount of DX tooling work to make it super-smooth to create a new project is _dwarfed_ by the amount of work to make monorepos...work...
* "Atomic commits across projects // One version of everything" - this is...actively bad? If I make a change to my library, I also have to change every consumer of it (or, worse, synchronize with them to make their changes at the same time before I can merge)? Whereas, in a polyrepo situation, I can publish the new version of my library, and decoupled consumers can update their consumption when they want to
* "Developer mobility - Get a consistent way of building and testing applications" - it's perfectly easy to have a consistent experience across polyrepos, and or to have an inconsistent one in a monorepo. In fairness I will concede that a monorepo makes a consistent experience more _likely_, but that's a weak advantage at best. Monorepos _do_ make it significantly harder to _deliberately_ use different languages in different services, though, which is a perfectly cromulent thing to permit.
-
What is the difference between monoliths, microservices, monorepos and multirepos?
The section on what monorepo tools should provide is useful if you are planning to set up an enterprise-level monorepo.
-
Contributing to the cause: doing it the open-source way
The next step would be to familiarize yourself with the codebase. Most of the repositories use monorepos for organizing and managing their code. A rule of the thumb here would be to make yourself familiar with what component lies in which place. It is next to impossible to understand the entire codebase at once. For starters, you can:
-
Joys and woes of monorepos
Monorepos are a great concept, especially in environments like Node.js which encourage having many small packages.
- Desenvolvendo APIs fortemente tipadas de ponta a ponta com tRPC
-
Confuse about TypeScript setup in monorepo
You might want to use monorepo tooling like NX, Lerna, or Turborepo to guide you. https://monorepo.tools/ has a list of tools.
- Monorepo Explained
-
Øyvind Berg and John De Goes discuss Bleep, the new config-as-data build tool
This explains it really well: https://monorepo.tools/
-
Good monorepo tooling
Have a look here to get some good context around monorepo tooling and if it’s something you actually need and want to do - https://monorepo.tools Some of the monorepo tooling can be a steep learning curve so you want to really think about the problem you are trying to solve and whether the effort will be worth it
zod
-
From Flaky to Flawless: Angular API Response Management with Zod
Zod is an open-source schema declaration and validation library that emphasizes TypeScript. It can refer to any data type, from simple to complex. Zod eliminates duplicative type declarations by inferring static TypeScript types and allows easy composition of complex data structures from simpler ones. It has no dependencies, is compatible with Node.js and modern browsers, and has a concise, chainable interface. Zod is lightweight (8kb when zipped), immutable, with methods returning new instances. It encourages parsing over validation and is not limited to TypeScript but works well with JavaScript as well.
- TypeScript Essentials: Distinguishing Types with Branding
-
You can’t run away from runtime errors using TypeScript
Zod is a TypeScript-first schema declaration and validation library. It helps create schemas for any data type and is very developer-friendly. Zod has the functional approach of "parse, don't validate." It supports coercion in all primitive types.
-
Best Next.js Libraries and Tools in 2024
Link: https://zod.dev/
-
Popular Libraries For Building Type-safe Web Application APIs
You can check out their documentation here.
-
Epic Next JS 14 Tutorial Part 4: How To Handle Login And Authentication in Next.js
You can learn more about Zod on their website here.
-
What even is a JSON number?
In JS, it's a good idea anyway to use some JSON parsing library instead of JSON.parse.
With Zod, you can use z.bigint() parser. If you take the "parse any JSON" snippet https://zod.dev/?id=json-type and change z.number() to z.bigint(), it should do what you are looking for.
-
Error handling in our form component for the NextAuth CredentialsProvider
We will validate our input using client-side zod. Zod handles TypeScript-first schema validation with static type inference. This means that it will not only validate your fields, it will also set types on validated fields.
-
Zod: Zero to Hero - Chapter 4
A word of warning: while discriminated unions are very powerful, there's an ongoing discussion on whether discriminated unions should be deprecated and replaced with a different API.
-
Zod: Zero to Hero - Chapter 1
I was first introduced to Zod by Adam Bobrow - a colleague of mine and a dear friend. Adam was sick and tired from JavaScript's brittleness, and about two years ago he started migrating our code base to TypeScript. But that wasn't enough for him. He kept complaining: "What good are my types, if some other service decides to send me bad data and breaks my code?". That's when he discovered Zod.
What are some alternatives?
ember-react-example - Example of invoking React components from an Ember app.
class-validator - Decorator-based property validation for classes.
nx-dotnet
joi - The most powerful data validation library for JS [Moved to: https://github.com/sideway/joi]
large-monorepo - Benchmarking Nx and Turborepo
Yup - Dead simple Object schema validation
bleep - A bleeping fast scala build tool!
typebox - Json Schema Type Builder with Static Type Resolution for TypeScript
lerna - :dragon: Lerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.
ajv - The fastest JSON schema Validator. Supports JSON Schema draft-04/06/07/2019-09/2020-12 and JSON Type Definition (RFC8927)
nx-recipes - 🧑🍳 Common recipes to productively use Nx with various technologies and in different setups. Made with ❤️ by the Nx Team
io-ts - Runtime type system for IO decoding/encoding