Something like additionalFields: true that will let the user add arbitrary keys to the objects.

This will let users create enums from object keys. May also provide a way to create enums from discriminant literals (tbd).

We already had this but I had to remove it when I was implementing the Python generator. Will need to reimplement.

Need to add this to the top of the file:

# yaml-language-server: $schema=https://json.schemastore.org/babelrc

We'll allow generating Zod schemas for a given definition.

Allow generating type aliases like

type ProjectsById = Record<string, Project>;

We'll be injecting validator functions into the specified firestore.rules file.

The following definition doesn't produce an error when it should. Instead, the generator produces a simple union.

Pet:
  model: alias
  type:
    type: union
    discriminant: type
    variants:
      - type: object
        fields:
          type:
            type:
              type: literal
              value: dog
          breed:
            type: string
      - type: map
        of: string

Need to make sure definition/schema.ts is consistent with definition/types.ts. Can be done with tsd tests.

For Python, we're creating classes on the fly. We need to properly handle name clashes. E.g. if we're supposed to create UserCredentials that already exists, we'll need to do something like UserCredentials2

Hi - thanks for creating this project, was looking for something to help with this exact use case as have a mixed Python BE and TS FE using Firestore with both.

Have a few feature ideas that I hope help make the library more useful (some of which already have open "Issues" so are hopefully planned):

• Right now I can only create a map as an Alias, and then use that to a Document - would be great to specify on the Document directly (dup of #87?)
• An Unknown, or Any type would be really useful for more freeform schemas (dup of #57?)
• Ability to support additional (typed or Any type) properties on a document, atm I am collecting them in a nested map but this makes the code more complex

Some nice to haves in the future,

• Ability to use an existing Pydantic parent class or Config
• Support for Firebase SERVER_TIMESTAMP

Thanks!

Fields are not properly indented

The additionalFields config on object types currently does not have an effect on Swift output.

We should allow documents to be modeled as a discriminated union.

Something like --custom-pydantic-base=x.y.MyModel that would produce:

import x.y.MyModel

class TypesyncModel(x.y.MyModel):
    ...

class Example(TypesyncModel):
    ...

For now, we should just do --outFile