サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
普段から TypeScript で開発されているほうならば、TypeScript の恩恵を十分に堪能されていることと思います。 特に私は VS Code のインテリセンスには頼りっぱなしでこれがなければまともにコーディングができない体になってしまいました。 しかし時には、TypeScript という概念が存在しない退屈な世界で開発を行わなけらばならない状況はあるでしょう。私はもはやキーボードでタイピングすることすらままなりません。 そんな JavaScript しか利用できない状況で代替手段となるのが、JSDoc です。JSDoc のアノテーションによって型を付与することによって最低限の支援を受けることができます。 @Type @Type タグを使用すると、TypeScript で型をつけるときと同じように型を宣言できます。
TypeScriptの主要な入力ファイルは .ts, .tsx, .mts, .cts ですが、JavaScriptファイル (.js, .jsx, .mjs, .cjs) も読み込んで処理することができます。JSDocによる型アノテーションを認識するため、生のJavaScriptでもそれなりに型をつけることができます。 本稿ではタイトル通り、TypeScriptのJSDocサポートでできることとできないこと (.ts でしかできないこと) をまとめます。 おことわり 本記事はTypeScript 4.4時点での実装状況に基づいています。なるべくソースコード中の関係する箇所を参照するようにしたので、今後の変更はご自分で検証してください。 (TypeScript Playgroundで試すだけでも有用です JavaScriptモードで開始できるリンク) JSDocの機能一覧・TypeScri
公開しているライブラリほどじゃないにせよ、チームで開発しているTypeScriptで書いたコードにちらほらドキュメンテーションしていきたい。 それESLintで とりあえず今までろくに書いていなかった部分はいまさっき書き足すPull Requestを作ったけれど、今後手を入れる時にもちゃんと書いていってほしい。 で、こういうルールの徹底を人間がレビューで「ドキュメントおねがいします」って言うのは不毛。2020年代にやっていいことではない。 TypeScript/JavaScriptでやろうとなったらESLintでどうにかしたい。eslint-plugin-jsdocがJSDocに関連したルールを提供している。 JSDocはTSDocと基本的なフォーマットは同じで細かいタグのセマンティクスは差異がありそう。 そしてなんとeslint-plugin-jsdocはTypeScriptもサポートし
これはなに コードベースに対し JSDoc の記述を必須化するための ESLint 設定手順をまとめたものです。 JSDoc を始めとする Doc コメントはコードに最も近いドキュメントであり、これがあるのと無いのとではコードベースの保守性に天と地ほどの差が生まれます。そんな JSDoc ですが、OSS ならともかく（内製・受託を問わず）商業ソフトウェア開発の現場では軽視されがちです。後からコーディング規約を定めたところで開発メンバーにドキュメントを書く習慣が備わっていなければ書き漏れが頻発するのが関の山です。 コードレビューで都度指摘するにはあまりにコストがかかるため、ESLint に委ねるのが望ましいです。 前提 フレームワークは React（or Next.js）を使っている。 TypeScript を主体としている。 ビルドスクリプトや設定ファイルは JavaScript も併用し
以下のリストは、JavaScriptファイルの型情報を提供する JSDocアノテーションにおいて、現在サポートされている構文の概要です。 以下に明示的にリストに入っていないタグ(@asyncなど)はまだサポートされていないことに注意してください。 @type @param (or @arg or @argument) @returns (or @return) @typedef @callback @template @class (or @constructor) @this @extends (or @augments) @enum class拡張 プロパティ修飾子 @public、@private、@protected、@readonly タグの意味は通常、jsdoc.appで与えられたものと同じか、あるいはそのスーパーセットです。 以下のコードでは、それぞれのタグの違いを説明し、使
For a variety of reasons, I prefer to write my code in vanilla JavaScript with JSDoc comments rather than writing in TypeScript. Today’s smart code editors, like Visual Studio Code, are able to read type information from JSDoc and provide Intellisense options as you code. However, those consuming your code may not get the same benefit unless you include a TypeScript declaration file along with the
As web development has embraced static typing during the past decade, TypeScript has become the default language of choice. I think this is great—I love working with TypeScript! But what if you can’t use TypeScript? You may encounter circumstances where you need to work in plain JavaScript, be it tooling constraints or a team member who does not like static typing. Under these circumstances, look
まとめたいなと思ったが、それは叶わぬ夢なのかもしれない・・・。 JSDoc.app Use JSDoc: Index https://jsdoc.app/#block-tags JSDocの本家（のはず）で、用途は主にドキュメント作成。 以下がその一覧で、AtoZ（エイリアスは別）順。 まずはブロックタグといわれるよく見るもの。 @abstract @virtual @access <package|private|protected|public> @alias <aliasNamepath> @async @augments <namepath> @extends <namepath> @author <name> [<emailAddress>] @borrows <that namepath> as <this namepath> @class [<type> <name>] @c
はじめに 私は vitest を使ってテストコードを実装することが多い。vitest は vite と統合されていることで変換処理に vite と同じプラグインが使えるため、開発時に vite を使っていれば追加で必要な設定が少ないという利点があるのだが、私は In-Source Testing という機能が気に入っていることが大きな理由だ。 これは他の言語でもよくある、実装コードと同じファイル内にテストが記述できるというものだ。 これにはいくつか利点があるが、その中でも、テストを実装の近くに置くことでテストが実装の説明するという役割を強めるという点がある。 このテストが実装の説明する点に注目したときにドキュメント内にテストを書くというアプローチもある。これはドキュメンテーションテストと呼ばれることがあり、いくつかの言語では実装されて用いられている。 vitest においてはプラグインの実
JSer.info #522 - @sindresorhusによるNode.jsライブラリのESM(ECMAScript Module)対応についてのdiscussionsが作られています。 @sindresorhusはさまざまNode.jsライブラリを作成しているため、Node.jsのESM対応に関係してきます。 The ESM move · Discussion #15 · sindresorhus/meta 2021-04-30でNode.js 10のLTSが終了し、Node.js 12以上のみが対象となります。 Node.js 12.xにはECMAScript modules(.mjsや"type": "module"など)の対応が含まれています。 nodejs/Release: Node.js Release Working Group Modules: ECMAScript m
JSDocコメントの有効活用。JavaScriptやTypeScriptのドキュメントを生成する方法 記事「JavaScriptでJSDocコメントを書くメリットとは」でJSDocコメントの有用性について紹介しました。その中で「APIドキュメントの書き出し」をメリットの1つとして取り上げています。 APIドキュメントの利用用途として以下が挙げられます。 JSライブラリの使い方を参照しやすくするため、APIドキュメントとして公開したい 他の開発チームへモジュールの使い方を説明するために、APIドキュメントを用意したい プロジェクトのJavaScriptコードを使って、形式的な納品物の成果物を作りたい 本記事ではAPIドキュメントの作成方法を解説します。 サンプルの紹介 サンプルをGitHubに用意していますので完成系をご覧ください。サイドバーを使うことで関数や定数などのドキュメントをたどるこ
JSDocは、JavaScriptのソースコードにアノテーション(注釈)を追加するために使われるマークアップ言語である。JSDocをコメントの中に含めることで、プログラマーは自分が書いたコードのAPIを記述するドキュメントを追加することができる。JSDocをさまざまなツールで処理することで、HTMLやRich Text Formatなどの形式のアクセス可能なドキュメンテーションを自動生成することができる。JSDocは、Apache License 2.0の元にライセンスされている自由ソフトウェアである。 JavaScriptをドキュメントするためにJavadocに似た構文を使用した最初期の使用例[要出典]は、1999にリリースされたNetscape/MozillaプロジェクトのRhinoである。これは、Javaで書かれたJavaScriptのランタイムシステムである[1]。 JSDocの構
const unified = require('unified') const { parser } = require('@geut/jsdast') const tree = unified().use(parser).parse(` /** * @param {number} a * @param {number} b * @returns {number} */ function sum(a, b) { return a + b } `) console.log(JSON.stringify(tree, null, 2)) /* { "type": "Root", "children": [ { "type": "Module", "name": "Index", "doc": { "description": "", "tags": [] }, "children": [ {
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
