Custom linter checks of Typegoose code

[4m4rel]

Hi,
I did manage to create two custom ESLint rules to check Typegoose schemas' code and detect possible issues.
Maybe you can advise more places to check or suggest improvements for the rules?

This rule checks for inconsistencies between Typegoose and Typescript property definitions, requirement option, to be precise: if property is required for Typescript (! operator used) but optional for Typegoose (required property is set to false or omitted in @prop) and vice versa

This rule checks for property type annotation and if it's going to be implicitly marked as Mixed by Typegoose (string[] for example, will be marked as Mixed if you won't provide type: () => [String] option for @prop decorator), throws an error

[hasezoey]

looks great, didnt know this was really possible.
some suggestions, but i dont know if they will be possible:

• if Ref<Class> is used, then option type is implicitly set to type => ObjectId and does not need a explicit option, but when using something like Ref<Class, String> typegoose will still implicitly use type => ObjectId unless type => String is set, see Reference other classes with different _id type
• if refPath is used, check that that path actually exists (if possible to check), see @prop option refPath
• for the mixed check, also check for the property allowMixed (on the property itself, and maybe the class), see @prop option allowMixed
• check for options that are not appropriate for the current type, like setting max(which is a Number-only option) on a String, see String options as a example
• check that virtual populate types are a array, unless justOne or count is set, see Virtual Populate Options

PS: i converted this to a discussion as this is not really a issue

[4m4rel]

• if Ref<Class> is used, then option type is implicitly set to type => ObjectId and does not need a explicit option, but when using something like Ref<Class, String> typegoose will still implicitly use type => ObjectId unless type => String is set, see Reference other classes with different _id type

that's interesting, thanks, I need to check if I can inspect generic types during linting
Also a question regarding Ref<..> type - is there a need to check for ref: () => ... property existence in @prop decorator when it is used?

• if refPath is used, check that that path actually exists (if possible to check), see @prop option refPath

great idea, will check that as well
I thought about checking localField property for virtual fields due to the same reason, what do you think?

• for the mixed check, also check for the property allowMixed (on the property itself, and maybe the class), see @prop option allowMixed

for this the default warning logic of Typegoose should be enough, but will keep in mind, thanks

• check for options that are not appropriate for the current type, like setting max(which is a Number-only option) on a String, see String options as a example

tricky one, looks like it will need an update when new transform option is added

• check that virtual populate types are a array, unless justOne or count is set, see Virtual Populate Options

that's handy, it could catch some possible issues as well, thanks

[hasezoey]

Also a question regarding Ref<..> type - is there a need to check for ref: () => ... property existence in @prop decorator when it is used?

yes you could also check that option ref is set when type Ref<> is used

I thought about checking localField property for virtual fields due to the same reason, what do you think?

you can, though i dont know how viable it is to check the dottet paths (which can be possible for those options)

[4m4rel]

Is there any chance you can create official eslint plugin for Typegoose based on what I did?
It would be very helpful for folks like me, who are migrating from mongoose or implementing something from scratch. Could decrease amount of issues and questions from users as well :)

[hasezoey]

i may consider it, but dont count on it