Consider forcing the explicite definition of return types within this repo

[jorroll]

FYI, I've noticed that this repo does not manually define the return type of many exported functions. I also maintain a typescript repo (rSchedule) and I used to not manually define return types. This worked fine for quite a while (a year or two) until one day I pushed out an update and found users complaining of type errors.

In my case, it turned out declaration merging within a test was resulting in the repo's development environment (i.e. editor) having different inferred types than what end users saw when they consumed the package in their own projects. More broadly, when you don't explicitly define the type of an export, then typescript infers the type and then hardcodes that inferred type into the compiled typescript declaration file that is included on npm. Sometimes this inferred type is different than what you expect/realize.

For most repos, I don't think requiring explicite return types is worth the trouble. But for a repo like solid-js, which I expect has aspirations to be widely adopted, forcing explicite return types via a lint rule seems like a good long-term bit of hygiene.

I totally respect if this isn't something you feel is appropriate/necessary (it is a lot of trouble for a questionable benefit), but figured I'd pass along my experience.

[ryansolid]

This seems like a really good idea. The TypeScript is largely community driven as I tend to not use TS beyond small demos and honestly am just not aware of gaps like this. I've also never considered a linter because of how particular I can be around how JavaScript is written for performance in some cases. But for TS that could be helpful. It just never crossed my mind of doing so for only this.

[jorroll]

The TypeScript is largely community driven as I tend to not use TS beyond small demos and honestly am just not aware of gaps like this.

I don't know how much of a common practice this is for "typescript as large". I first encountered a repo that required explicite return types two years ago when I submitted a PR for Deno. At the time, I found Deno's requirement to be very annoying. Later, I found RXJS also widely defines explicite return types (for example), though they don't seem to use a lint rule to enforce this (I notice that, in this file, they appear to explicitly define the return type of all exported functions but not of private functions--which makes sense if they are only trying to avoid end user type issues). I didn't see the benefit for explicitly defining return types myself until I ran into an issue.

The great majority of typescript repos I've contributed to are small Angular ones and they have not explicitly defined return types. It still doesn't strike me as worth the hassle for most libraries, but most libraries are not as important to a project as Solid is (or Deno, or RXJS). Even when making the decision to explicitly define return types, as rxjs seems to show its debatable if using a lint rule is necessary.