DEV Community

Cover image for Boost Your JavaScript with JSDoc Typing

Boost Your JavaScript with JSDoc Typing

Samuel Braun on April 08, 2023

There are many reasons why you can't or don't want to use TypeScript in your project. One common reason is that you are using a legacy codebase tha...
Collapse
 
darkterminal profile image
Imam Ali Mustofa

This is what am looking for. Thanks @samuel-braun πŸ”₯πŸ”₯

Collapse
 
beebase profile image
Maarten Berkenbosch

I can't find any documentation about linking namespaces modules memberof etc etc.
I'm looking for examples with a hierarchy.
eg.

backend/logic/api.js (with methods and variables)
backend/logic/cache.js

How do I set this up?
namespace: backend ?
module: logic?
api: memberof logic?

functions in api.js memberof api ?

I have no clue how to organise this and on top of that @link syntax is so confusing (and doesn't work most of the time)

Collapse
 
samuel-braun profile image
Samuel Braun • Edited

Im not too sure what you are looking for, but here is how you could use namespaces and modules to structure your code:

api.js

/**
 * @namespace backend
 */

/**
 * @module api
 * @memberof backend
 */

/**
 * A function in the api.js file.
 * @function someFunction
 * @memberof module:api
 */
function someFunction() {
  // your code here
}

/**
 * A variable in the api.js file.
 * @var {number} someVariable
 * @memberof module:api
 */
const someVariable = 123;
Enter fullscreen mode Exit fullscreen mode

cache.js

/**
 * @module cache
 * @memberof backend
 */

/**
 * A function in the cache.js file.
 * @function anotherFunction
 * @memberof module:cache
 */
function anotherFunction() {
  // your code here
}
Enter fullscreen mode Exit fullscreen mode

anywhereElse.js

/**
 * This function does something with {@link module:api.someFunction}.
 */
function yetAnotherFunction() {
  // your code here
}
Enter fullscreen mode Exit fullscreen mode
Collapse
 
sergeyleschev profile image
Sergey Leschev

I would like to stress the importance of writing clean and maintainable code. It's essential to keep in mind that the code we write is not just for us but for others who might work on the project in the future. Therefore, it's crucial to follow coding standards and best practices, choose descriptive and meaningful variable names, and write comments wherever necessary to make code more readable and understandable.

Another crucial aspect of writing quality code is testing. Testing should be an integral part of the development process, and all code changes should undergo automated tests to ensure that they are working as expected. This helps catch bugs early on and saves time and effort in identifying and fixing them later in the development cycle.

Collapse
 
samuel-braun profile image
Samuel Braun

Absoloutely Sergey πŸ‘, It's like you read my mind. Im currently writing a post about that exact topic (variable naming and code readability). Im just waiting to get approval to use a piece of code as an example and I can publish it. So it'll be around start of next week.

Collapse
 
mroeling profile image
Mark Roeling

wondering: does it help in "parsing" runtime, in a browser? What is the effect perfomance-wise?

Collapse
 
samuel-braun profile image
Samuel Braun • Edited

Not sure exactly what you mean with parsing at runtime. JSDoc wasn't meant to be run in the browser. But if you want to validate types for exmaple of an API you could use something like Zod. With Zod you can also type your code using the same schema a JSDoc:

const myUserSchema = z.object({
    user: z.string(),
    age: z.number(),
});
// @type {z.infer<typeof myUserSchema>}
const user = await fetch("user.json");

// Validate if data is actually same type as defined in the schema
// Throws an error if not
myUserSchema.parse(user);
Enter fullscreen mode Exit fullscreen mode
Collapse
 
chema profile image
JosΓ© MarΓ­a CL

Great article!

Collapse
 
kevinast profile image
Kevin Bridges • Edited

Great article Samuel ... thanks for sharing.

FYI: There is a minor fo paux in the "Other JSDoc tags" section, where a previous code sample has broken the article content into a coding pre tag.

Collapse
 
samuel-braun profile image
Samuel Braun

Thank you for telling, I've fixed it βœ”

Collapse
 
farcellier profile image
Fabien Arcellier • Edited

This is exactly the wrap up I was looking for. I enjoy the attention to details you have done @samuel-braun.

I would appreciate to have a way to navigate quickly in the article. Have you considered to add a table of content in the article ? (@derlin has developped a toc generator for dev.to if you need)

Collapse
 
samuel-braun profile image
Samuel Braun

Thank you for this suggestion, thats a great idea. Aaand Done!

Collapse
 
t7yang profile image
t7yang

I did write a very similar article two years ago.
But not many people know.
dev.to/t7yang/type-safety-in-javas...

Collapse
 
fruntend profile image
fruntend

Π‘ongratulations πŸ₯³! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up πŸ‘

Collapse
 
samuel-braun profile image
Samuel Braun

Wow, I didnt expect my first post to explode like that. Thank you all for the kind words and feedback. I will definitely continue writing more posts in the future. ❀

Collapse
 
webreflection profile image
Andrea Giammarchi

I love TS in JSDoc and this post seems to have nailed down most common questions with examples and reasoning. Thank you!

Collapse
 
mkvillalobos profile image
Manrike Villalobos BΓ‘ez

WONDERFUL article! Thank you so much!!!

Collapse
 
vhs profile image
vhs

It's also possible to create a types.d.js file for app-wide type definitions.

Collapse
 
samuel-braun profile image
Samuel Braun

Absolutely, it's described in more detail here: #dts-files

Collapse
 
renatobritodev profile image
Renato Brito

Wow! This article is amazing and easy to understand. Thanks, @samuel-braun .

Collapse
 
typhonrt profile image
Michael Leahy

Great article @samuel-braun; I refer a lot of folks to it. I just want to drop a potential valuable resource for folks that are going down the JSDoc + TS route and this is a NPM package I've been developing for the past 1.5 years for automatic TS declaration generation from ESM / JSDoc: @typhonjs-build-test/esm-d-ts. It has all sorts of nice features for library developers including support for sub-path exports and more. If you think it is a good resource to add to the "Additional Resources" section of the article that's awesome.

In the coming months I'm also working on a package w/ a CLI to automatically generate documentation from the generated TS declarations from ESM + JSDoc.

Collapse
 
evergrowingdev profile image
Cherlock Code πŸ”Ž

Thank you for this great and thorough explanation of using JS docs. I've recently been exploring using them myself so this was very insightful :)

Collapse
 
samuel-braun profile image
Samuel Braun • Edited

Thanks alot, I'm happy you liked it. At my company we're currently adapting JSDoc and its a big change for everyone writing JavaScript. I often end up helping them with doing their types. So I hope this gets rid of their confusion and other developers aswell.

Collapse
 
howsmyanimeprofilepicture profile image
howsmyanimeprofilepicture

Well summarized post. I am using this post as my JSDoc cheatsheet. Thank you!

Collapse
 
xuumies profile image
Xoomies

This is very in-depth! Great explanation! I will definitely be referencing this for any JSDoc projects I might have! Thank you!