Replies: 3 comments
-
Personally I think it's not that important to be fully uniform about this. The jsdocs I don't mind at all establishing some kind of more strict norm, just presenting the case for incrementalism/agility over uniformity. I can be down with anything, especially if we have ci robots enforce all style policies (e.g. by a linter or other static analysis). |
Beta Was this translation helpful? Give feedback.
-
Thanks for raising this @Bengo. We use jsdocs in most of our projects to have types while dev, as well as to generate types on client releases. But recently, for things like bindings in CF Workers we have been moving to use a bindings.ts file, which personally have been super helpful for me while developing. Having extra types as needed declared in types files rather than jsdocs is something that I am ok with, but don’t know if it brings a lot of value. For defining interfaces though, that is super valuable. I feel like we can start using more typescript files for types/interface declarations, but would like to define a standard to use by the whole team, instead of having all project differently. |
Beta Was this translation helpful? Give feedback.
-
What we do now is a mix of jsdoc for simple stuff and a .ts (not .d.ts) file for complex types definition and that works pretty well. if you want to avoid the bigger I also have been crafting for a long time a stable, 0 conflicts config for ts, eslint, standard and prettier here https://github.com/hugomrdias/hd-scripts |
Beta Was this translation helpful? Give feedback.
-
Motivation:
.ts
file in this pr. Previously we mostly just use jsdoc@typedefs
Notes:
1 vote ·
Beta Was this translation helpful? Give feedback.
All reactions