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...
For further actions, you may consider blocking this person and/or reporting abuse
This is what am looking for. Thanks @samuel-braun π₯π₯
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)
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
cache.js
anywhereElse.js
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.
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.
wondering: does it help in "parsing" runtime, in a browser? What is the effect perfomance-wise?
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:
Great article!
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.
Thank you for telling, I've fixed it β
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)
Thank you for this suggestion, thats a great idea. Aaand Done!
I did write a very similar article two years ago.
But not many people know.
dev.to/t7yang/type-safety-in-javas...
Π‘ongratulations π₯³! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up π
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. β€
I love TS in JSDoc and this post seems to have nailed down most common questions with examples and reasoning. Thank you!
WONDERFUL article! Thank you so much!!!
It's also possible to create a
types.d.js
file for app-wide type definitions.Absolutely, it's described in more detail here: #dts-files
Wow! This article is amazing and easy to understand. Thanks, @samuel-braun .
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.
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 :)
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.
Well summarized post. I am using this post as my JSDoc cheatsheet. Thank you!
This is very in-depth! Great explanation! I will definitely be referencing this for any JSDoc projects I might have! Thank you!