release

Fresh v1.1がリリースされました。 この記事では主な変更点などについて解説します。 アップデート用スクリプトの追加 Freshのアップデート用スクリプトが追加されています。 $ deno run -A https://fresh.deno.dev/update . このスクリプトを実行すると、各種依存関係や後述するcompilerOptionsやTwindプラグインなどに関する変更が適用されます。 compilerOptions.jsxとcompilerOptions.jsxImportSourceのサポート Freshのプロジェクトの初期化時に、compilerOptions.jsxとcompilerOptions.jsxImportSourceが自動で設定されるようになりました。 これにより、.jsx/.tsxファイルで以下2行の指定が不要になります。 /** @jsx h */ import { h } from "preact"; 前述のアップデートスクリプトを実行すると、既存のプロジェクトにもこの設定が適用されます。 プラグインシステム ユーザがFreshの挙動を拡張できるようにするために、プラグインシステムが実装されました。 現時点では、生成されたHTMLに対するスクリプトやスタイルの注入などがサポートされています。将来的には、プラグイン経由でRouteやMiddlewareなどを追加できるようにすることが予定されているようです。 例として、公式でTwindプラグインが提供されており、start()のpluginsオプションで有効化できます。 // main.ts import { start } from "$fresh/server.ts"; import twindPlugin from "$fresh/plugins/twind.ts"; import manifest from "./fresh.gen.ts"; import twindConfig from "./twind.config.ts"; await start(manifest, { plugins: [twindPlugin(twindConfig)] }); このTwindプラグインを有効化すると、twを使わずにclassを指定できるようになります (PreactのOption Hooksを使用して twが自動で適用されます) <div class="font-bold">foobar</div> 前述のアップデートスクリプトを実行することで、twを使わずにclassを記述する形式へ自動で変換されます。 Preact Devtoolsのサポート Preact Devtoolsのサポートが追加されています。 devモード(deno task start)時は自動で有効化されるため、特に設定などは不要です。...

Deno v1.25がリリースされました。 この記事では主な変更点などについて解説します。 npmパッケージのサポート Denoでnpmパッケージのimportや実行が実験的にサポートされました。 npm installやnode_modulesなどを必要とせずにnpmパッケージを利用することができます。 import express from "npm:express@4.18.1"; const app = express(); app.get("/", (req, res) => { res.send("Hello"); }); app.listen(3000); このファイルを実行すると、npmパッケージがダウンロードされた後、ExpressによってHTTPサーバが起動します。 $ deno run --unstable --allow-env --allow-read --allow-net main.mjs $ curl http://localhost:3000 Hello 他のサードパーティモジュールなどと同様に、初回実行時のみnpmパッケージがダウンロードされ、DENO_DIRにキャッシュされます。(DENO_DIR/npm/registry.npmjs.orgに保存されるようです) また、npxライクにコマンドを実行することもできます。 $ deno run --unstable --allow-env --allow-read --allow-write npm:make-dir-cli@3.0.0 src/components 制限 現時点では利用するには--unstableが必要になります。 また、--allow-envや--allow-readも必要になります。 ロックファイル/型チェック/deno vendor/deno lsp/deno installなどでは、この機能はまだサポートされていません。 新しいHTTPサーバ (Flash) DenoにはHyperをベースにしたHTTPサーバ(Deno.serveHttp)が組み込まれています。 このHTTPサーバのさらなる高速化などを目的に、Flashという新しいHTTPサーバが実装されました。 Deno.serveというAPIによって、Flashを起動することができます。 const ac = new AbortController(); Deno....

Deno v1.24がリリースされました。 この記事では主な変更点などについて解説します。 --checkオプション指定時のトランスパイルの挙動が変更 tscがトランスパイル用途では使用されなくなりました。 型チェック トランスパイル --check (v1.23) tsc tsc --no-check (v1.23) - swc --check (v1.24) tsc swc --no-check (v1.24) - swc これにより、トランスパイルの効率化が見込まれます。 また、tscの実行結果をSQLiteにキャッシュする仕組みも導入されており、型チェックについても効率化が図られています。($DENO_DIR/check_cache_v1にSQLiteのデータベースファイルが作成されます) FFI(Deno.dlopen)の改善 v1.23.3でV8 Fast API Calls+JITコンパイルの導入による最適化が実施されました。 今回のリリースでは、64ビット値を取り扱う関数に対してもV8 Fast API Callsを利用した最適化が適用されるように改善されています。 サブプロセスAPIへの変更 Deno v1.21 で入ったサブプロセスAPIに変更が加わっています。 Deno.Child.unref()とDeno.Child.ref()のサポート 挙動としてはDeno.refTimerやDeno.unrefTimerと同様で、Deno.Child.unref()を呼ぶと、対象の子プロセスがDenoの終了をブロックしなくなります。 const child = await Deno.spawnChild("some_long_running_process", { args }); child.unref(); (破壊的変更) Deno.Childの型定義が変更 Deno.spawnChildで返却されるDeno.Childのstdio関連のプロパティに関する型定義が変更されています。 v1.23.4...

Deno v1.23がリリースされました。 この記事では主な変更点などについて解説します。 deno runやdeno cacheなどのコマンドでデフォルトの型チェックが無効化されました 下記コマンドで、デフォルトで型チェックが行われなくなります。 deno run deno cache deno eval deno repl 今後、型チェックを行いたい場合は、deno checkコマンドを使うか--checkオプションを指定する必要があります。 $ deno check mod.ts その他のdeno testなどのコマンドでは、引き続きローカルモジュールの型チェックがデフォルトで実行されます。 deno runが失敗する場合の対処方法 Denoは、型チェックを行わない場合、swcを使用してトランスパイルを行います。 その関係で、コードの実行時に、まれに問題が発生することがあるようです。 https://github.com/denoland/deno/issues/14900 問題に遭遇した場合は、--checkオプションを指定するとtscが使用されるため、問題を回避できる可能性があります。 $ deno run --check mod.ts Deno.sleepSync()の削除 Atomics.waitで代替可能であったり、イベントループを完全にブロックしてしまうなどの問題を抱えていたため、Deno.sleepSync()が削除されました。 Intl.v8BreakIteratorの削除 非標準APIであるため、Intl.v8BreakIteratorが削除されました。 代わりにIntl.Segmenterの使用が推奨されます。 deno taskコマンドの改善 --cwdオプションのサポート --cwdオプションにより、タスク実行時のカレントディレクトリを変更できるようになりました (デフォルトでは、deno.json(c)の配置場所がカレントディレクトリに設定されます) $ deno task --cwd ./src build リダイレクションのサポート タスクの定義でリダイレクションがサポートされました。 { "tasks": { "test": "echo foo > test.txt" } } また、/dev/nullにリダイレクトすると、出力が捨てられます (Windowsでも動きます)...

Deno v1.22がリリースされました。 この記事では、主な変更点についてまとめていきます。 リモートモジュールの型チェックがデフォルトで無効化 deno runやdeno testなどの各コマンドでリモートモジュールの型チェックがデフォルトで無効化されました。 今後はローカルのTypeScriptファイルのみが型チェックされます。 もしリモートモジュールの型チェックも必要な際は--check=allオプションまたはdeno check --remoteを使用します。 また、次のv1.23のリリースでは、deno runやdeno cacheではデフォルトで一切型チェックが行われなくなる予定です。 (deno checkコマンドや--checkオプションなどで明示的に型チェックする必要があります) 例えば、CIでdeno cacheコマンドを実行して型チェックを行っている場合などは、今のうちにdeno checkコマンドに移行しておくとよいと思います。 # mod.tsの型チェックを行う $ deno check mod.ts # deno run実行時に型チェックも行う $ deno run --check main.ts 設定ファイルの読み込みの無効化 Denoはエントリポイントが存在するディレクトリまたはその上位のいずれかのディレクトリにdeno.json(c)というファイルが存在する場合、それを自動で読み込みます。 このリリースでは、新しく--no-configオプションがサポートされました。 このオプションを指定すると、deno.json(c)の自動探索を無効化できます。 $ deno run --no-config main.ts (破壊的変更) Worker内でデフォルトでDeno APIが有効化 今までは、Worker内でDeno.readFileなどのAPIを使用したい場合は、denoオプションによって明示的に有効化する必要がありました。 new Worker(new URL('./worker.js', import.meta.url).href, { deno: { namespace: true }, // Deno APIの使用を有効化 type: "module" }); 今後は上記のようにオプションを指定しなくても、Worker内で常にDenoのAPIを参照できます。 new Worker(new URL('./worker.js', import.meta.url).href, { type: "module" }); また、この変更の影響により、WorkerOptions....

Deno v1.21がリリースされました。 この記事では新機能や修正点などについて解説します。 deno checkコマンドの導入 新しいコマンドとしてdeno checkコマンドが追加されました。 挙動としては基本的にdeno cacheコマンドと同等で、与えられたモジュールの型チェック及びリモートモジュールのダウンロードを行います。 $ deno check mod.ts deno cacheコマンドとの違い deno cacheコマンドとの大きな違いとして、deno checkコマンドはデフォルトではリモートモジュールの型チェックを行いません。 deno checkコマンドでリモートモジュールの型チェックも行いたい場合は--remoteオプションを指定する必要があります。 deno runコマンドでの型チェックについて deno checkコマンドの追加による影響として、将来的にdeno runコマンドではデフォルトで型チェックが行われなくなる予定です。(Deno v1.21時点でもDENO_FUTURE_CHECK=1環境変数を設定することで、この挙動を有効化できます) 型チェックを行いたいときは、今回追加されたdeno checkコマンドまたはdeno run --checkで明示的に行う必要が出てきます。 新しいサブプロセスAPI (unstable) DenoにはDeno.run()というサブプロセスを生成するためのAPIがありますが、今回、新しく3種類のAPIが追加されました: Deno.spawn() (高レベル) Deno.spawnChild() (低レベル) Deno.spawnSync() (Deno.spawnの同期版) これらのAPIの利用にはDeno.run()と同様に--allow-runパーミッションが必要です。 また、これらのAPIの追加により、Deno.run()は非推奨化される予定のようです。 Deno.spawn() これは高レベルAPIという位置づけです。 指定したコマンドを実行し、そのコマンドの実行結果(status)や標準出力(stdout)及び標準エラー出力(stderr)への出力内容を返却してくれます。 const { stdout, status } = await Deno.spawn("echo", { args: ["foo"], }); console.assert("foo\n" === new TextDecoder().decode(stdout)); console.assert(status.success); コマンドの出力結果のみが必要で、細かな制御はいらない場合に便利かと思います。 Deno.spawnChild() こちらは低レベルAPIという位置づけです。 Deno.Reader/Deno.WriterではなくReadableStream/WritableStreamをベースに実装されています。 const child = Deno....

Deno v1.20がリリースされました。 この記事では新しく追加された機能などについて紹介します。 (破壊的変更) Deno.testのpermissionsオプションの挙動が変更 ⚠️ この変更はv1.20.1時点ではまだ反映されていません！ 現在、正式な修正用のPRが作成されており、おそらくv1.20.2で反映されるはずです https://github.com/denoland/deno/pull/14024 Deno.testやWorkerなどのAPIはpermissionsオプションにより実行時のパーミッションをカスタマイズできます: Deno.test({ name: "permissions_test", permissions: { read: true }, fn: async () => { const content = await Deno.readTextFile("./data.txt"); await Deno.writeTextFile("./data.txt", processContent(content)); }, }); 上記のテストコードはDeno.readTextFileとDeno.writeTextFileを実行しており、正しく実行するためには--allow-readと--allow-writeの両方の権限が必要です。 このテストケースでは、下記宣言により--allow-readを明示的に指定しています。 permissions: { read: true }, ここではwrite: trueが指定されていないため、このテストケースは権限エラーにより失敗するというのが直感的な挙動なのではないかと思います。 しかし、Deno v1.19時点では上記のテストコードは成功してしまいます。 permissions: { read: true }, 実は、Deno v1.19において、この指定は下記宣言と同義になります: // `read`以外はすべてCLIオプションで指定された権限(--allow-writeなど)が継承される permissions: { read: true, env: "inherit", ffi: "inherit", hrtime: "inherit", net: "inherit", run: "inherit", write: "inherit", }, この挙動は直感的ではないということで、Deno v1....