Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve TS Type Inference by extending Meteor Check Types #8

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ceigey
Copy link

@ceigey ceigey commented Jan 2, 2025

Relates to #7

Note:

I've run into some hiccups trying to figure out testing.

When I ran meteor test-packages ./ I got 157/173 tests passing with a defaults - insert - basic failing and a bunch of other tests "waiting". New to this so not sure what I should do to get those working (if anything. e.g. maybe out of scope).

However, these changes mostly affect type inference, which I'm not sure how to test properly yet.

The two changes that affect the runtime are in lib/attach where I made both client and server versions of attachSchema return this to match the Collection typing trick in the .d.ts file.

Three things two consider:

  1. Were types generated using the existing JS Doc types? If so, would you prefer I work from there instead of modifying the easy-schema.d.ts file? (happy to if preferred, especially given the new @import tag, but not sure if it'd affect declaration merging at all)
  2. I can't find a good way to type Collection based on the attached schema without erasing the type of the output of transform.
  3. Should this export an alias of PatternMatch that's something like Valibot's InferOutput?

My best attempt at fixing the second issue was something like:

declare module 'meteor/mongo' {
  namespace Mongo {
    interface Collection<T, U = T> {
      attachSchema<P extends Pattern, T, U>(this: Collection<T, U>, schema: P): Collection<PatternMatch<P>, T extends U ? P : U>
      schema?: Pattern;
    }
  }
}

which infers U correctly, but it's not that clean. So I didn't implement it for now. I think if someone really wants a typesafe Collection<T, U> they might need to use TypeScript and pass in something like:

import type { PatternMatch } from 'meteor/jam:easy-schema'
type MyDoc = PatternMatch<typeof MySchema>
const coll = new Mongo.Collection<MyDoc>('blah', { transform(doc) { .... } })
coll.attachSchema(MySchema)
export coll

My testing is currently done manually by git cloning my branch into a new Meteor v3 project. I've played around with Collection declarations & the check function.

Edit: I haven't used ValidatedMethod so I'm not sure if there's a risk of breakage.

Screenshot 2025-01-03 at 3 37 52 am

Happy for any feedback or to follow any additional steps - this is my first time contributing to a Meteor package I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant