Intro thread: Welcome discussing how to use types in plain JS!

[voxpelli]

Hello and welcome!

We're increasingly many who love types but are no big fans of transpiling, so we're gathering us all here to discuss ways of using types in plain JS. (Mainly by using TypeScript and JSDoc together with one another)

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community!

[Raynos]

Hi, I'm @Raynos

I've been using JSDoc more frequently when working on existing codebases where the team has no energy or desire to migrate to TypeScript.

I've written a tool called https://github.com/Raynos/tsdocstandard for myself which helps me convert plain JS or TS to JS+JSDoc without losing type safety.

[voxpelli]

I'm @voxpelli

I've started out using JSDoc to retrofit types into existing projects, avoiding any major rewrite into TypeScript and avoiding the additional tooling that would require. Types in JSDoc enabled me to progressively enhance my teams code to become ever more typed.

It worked well, so now I use TypeScreipt validated JSDoc comments in all of my projects and nowadays for my libraries I also compile those JSDocs to TypeScript definition files (.d.ts) when I publish them to npm and I also at times add an advanced-types.d.ts to my projects where I handcraft some types which I can import and use in my JS (like @type {import(./advanced-types).Foo})

Like @Raynos I have worked a bit on the linting in relation to types and published that as @voxpelli/eslint-config-jsdoc-ts. Mine is just a TypeScript focused configuration of eslint-plugin-jsdoc though, which I myself use in my @voxpelli/eslint-config.

Right now I'm working on my first new larger project since going freelance again and my first new larger project since going all in on types in JS. This project utilizes fastify together with JSON schemas which gets compiled to TypeScript definitions as well as a GraphQL schema that also gets compiled to TypeScript definitions. All in all, leveling up my type game.

[Gozala]

Hi All,

I’m @Gozala or Irakli In IRL. I find myself doing more TS lately than https://flow.org/ (which I found to be far superior and which had a nicer comments for annotations).

As I like copy & pasting code from editor to repls I find types via comments provide a better experience at the cost of typing JSDoc. It is also easier to sell adding jsdoc comments to a team of JS devs than rewrite in TS.

So I find myself doing JSDoc+TS, running into problems, finding workarounds etc... I hope to learn thing or two and hopefully contribute thing or two 😊

One tool I end up working on in this space is https://github.com/Gozala/typescript-error-reporter-action which is a github action that reports results of type check inline in the diff view of the pull request. It started as a fork to fix an issue so it would work for my config, but end in almost full rewrite.

As of recently I have been contributing to an effort to entype js-ipfs, discovering more problems with TS and developing best practices

[voxpelli]

Sounds like a neat GitHub Action @Gozala! Thanks for joining in and sharing :)

[samthor]

Hello, I work at Google on the Web DevRel team. Earlier this week I wrote this blogpost which is covering an introduction to checking JS-with-TS. I always knew this was possible but sat down to write it because I felt like my JS-only projects could really benefit from some static analysis. (Also, I forgot that @voxpelli made this group.)

I used to work on Google's Closure Compiler, so I have sort of an encyclopedic knowledge of JSDoc and its types. Closure was great for bringing the web forward—although today it's slow and clunky, plus has a million flags no-one understands—so using TSC for type-checking only really appeals to me.

(Unrelated but I work on things like Santa Tracker, a bunch of polyfills, and our infrastructure projects. Some of these get statically type checked too.)

[Rizary]

Hey, mind to share your complete project that is open sourced and implement what you write in your blog?

[voxpelli]

Would love to collect examples here: #11 Also: Great to have you here @samthor! And great that you are joining in on the discussion as well @Rizary, I hope the questions will keep coming!

[samthor]

I'm slowly moving some libraries over to being typed (if I can stomach all the red).

I'm also rewriting Emojityper to use Web Components and types; that I will announce when it's up.

Unlike @voxpelli I haven't really worked out the autogeneration of .d.ts yet. I tend to write the types and then write an API to the types.

[joshuatz]

Hello everyone!

I'm Joshua Tzucker (joshuatz), and I'm glad to see that there is a growing movement to embrace type-safety in JS!

I've been using JSDoc powered type-safety for a fair bit of time now, but often got frustrated by the lack of documentation, so one thing that I've spent a decent chunk of time on is a JSDoc Cheatsheet that focuses on its use for Type-Safety. It covers a lot, but some more advanced sections include how to use generics, and type guards.

I currently use JSDoc-powered JS type-checking on a kind of "as I see fit" basis. I find that the ease-of-use, reduced setup, and lack of a transpilation / build step, make it great for quick snippets and tools, but for larger projects I sometimes find myself getting tired of the amount of boilerplate comments that are required to get the same type-safety as as a regular .ts file. In those cases, I either use full TypeScript, or use the hybrid approach - put most of my advanced types and interfaces in ambient declaration files (*.d.ts) or modules, and pull them into the JSDoc side. I think this approach is growing in popularity as well - see replies to this tweet (including yours, @voxpelli 😄).

Glad to have found this group!