Native ESM + TypeScript 拡張子問題: 歯にものが挟まったようなスッキリしない書き流し
Node.jsのNative ESM対応は夢の機能ですが、夢を詰め込みすぎたせいかCJSからの移行を難しくしているポイントが依然として存在します。そのひとつが拡張子問題で、Node.jsのNative ESMではモジュールの拡張子を明示しなければいけなくなりました。 (これはWebブラウザの挙動に近づけるための判断だと考えられます。) 特にTypeScriptと他のツール (JestやWebpack) と組み合わせて利用している状態でのNative ESM化は実質的に未解決の状態だと言えます。本稿ではこの現状についてできる範囲で状況説明を試みます。 Node.jsの拡張子の扱い Node.jsはCJSとESMの2つのモジュールフォーマットをサポートしていますが、これらは単にパーサーが異なるだけではなく、実質的には「2種類の異なるモジュールシステムがFFIで繋がっている」程度には隔たりがあり
Node.jsを過去の物にする最速の肉まん - Qiita
その名はBun ﾃﾞﾃﾞﾝ BunはNode.jsやDenoのようなJavascriptランタイムです。(2022/7/8現在ベータ版) ちなみにロゴが本当に肉まんなのかはわかりません。（赤ちゃんの頭にも見えるけど名前がBun/パンだしなぁ...) この記事ではNode.jsやDenoと比較をしつつ、bunの解説させていただきます。 割となんでもできる Bunはただのランタイムではありません。下のように、開発に必須の多くな機能を最初から有しています。 TypescriptからJavascriptへのトランスパイル jsxからJavascriptへのトランスパイル npmのようなパッケージのインストール&管理 webpackのようなプロジェクトのバンドル化 もちろんランタイムなのでNode.jsのようにサーバーでJavascriptを実行することも可能です。 これらに加えてBunには様々な機
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho
GitHub Pull-ReqでCIの完了をデスクトップ通知するChrome拡張 "WatchRaptor" を作った - Islands in the byte stream
Chrome Web Store chrome.google.com 使い方ですが、GitHub PR pageに次のようにCI statusにcheckboxが現れるので、完了通知がほしいCI statusにチェックをつけるだけ。 チェックされたCI statusが完了（success or failure）になると、次のようなデスクトップ通知が出ます。この完了したときの通知をクリックすると該当のGitHub PR pageのタブをアクティブにします。 tab idごとにcheck状態をもっているので、リロードしてもtabごとのcheck状態は維持されます。 現在（v0.9.2）の機能はこれだけです。既知のバグとして、GitHubのPR画面で差分をみたりdiscussionに戻ったりしているとcheckboxが出ないことがありますが、そういう場合はリロードするとcheckboxが出ると思
なぜWebpackの設定はTypeScriptで書けるのか？
この記事について webpack の設定ファイルであるwebpack.config.jsは、TypeScript で書いて Node.js 上で実行できます。しかし、本来であれば TypeScript のソースコードは Node.js では実行できないはずです。 この事が気になった私は、今回その仕組みを調べてみたので、この場を借りてその調査結果を共有したいと思います 💪 参照 記事の概要 概要のみ知りたい人に向けて、以下にこの記事で解説する内容をまとめておきます 👇 webpack-cli では、 rechoir を使って TypeScript を require() できるようにしているよ rechoir は、 ts-node などを使って require.extensions を拡張しているよ ちなみに、 require.extensions は非推奨だよ webpack-cli
esbuild で Node.js を TypeScript 化する
TLDR バックエンドのコードを esbuild で TypeScript 化した ビルド時間は1秒ほど tsc に比べて10倍以上高速化できた 特に問題なくプロダクションで安定稼働している esbuild はいつ使えるのか みなさん webpack は使っていますか？まだまだ広く使われていると思いますが、最近では esbuild の事例もたまに見るようになってきました。 ABEMAにesbuildを導入してWebのバンドル処理を69倍高速化した話 | CyberAgent Developers Blog esbuild が爆速すぎて webpack / Rollup にはもう戻れない | Kabuku Developers Blog 現時点で esbuild をフロントエンドの Bundler として導入するには、以下のような問題があります。 ES5にトランスパイルできない Code S
Pure ESM package
esm-package.md Pure ESM package The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS. This means you have the following choices: Use ESM yourself. (preferred) Use import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide. If the package is used in
Native ESM 時代のフロントエンドビルドツールの動向
No Bundle ツールの流行: vite / snowpack モダンブラウザは Native ESM を備えているので、開発時は高速な localhost アクセスを頼って直接 import する、外部ライブラリだけ事前にコンパイルしておく、という手法が流行ってきている。プロダクション用は今まで通りビルドする。 webpack はすべてを一つにバンドルするためにメモリ上にファイルの実体と依存グラフを持っているが、これによりメモリと CPU を圧迫する問題があった。特に巨大なリポジトリではそれが顕著になる。 No bundle ツールの実装として vite と snowpack がある。 https://github.com/vitejs/vite https://www.snowpack.dev/ vite は使ってみた限り、更新時の差分ビルドが爆速で、明らかに体感が良い。 Vue
Nuxt v3はどうなるのか - Qiita
2020/09/19にめでたくVue.js v3がリリースされました🎉 さて、私の関心は業務でも利用しているNuxt.jsがVue.js v3に対応するとどうなるのか、Nuxt.js v3はどうなっていくのか気になっています。 Vue.js Amsterdamで紹介されたNuxt.js v3のスライドから個人的に気になったところを抜粋して紹介します。 The State of Nuxt by Sébastien Chopin Nuxt 3 Architecture Updates by pooya parsa 詳しくはスライドを参照ください。 TypeScriptのサポート core や vue-appが型付になる @nuxt/typesやnuxt-tsが不要になる VueComponentのTypescriptサポート（SFC？） ランタイムとnuxt.configのサポート 現状はN
[Web フロントエンド] esbuild が爆速すぎて webpack / Rollup にはもう戻れない - 株式会社カブク
TypeScript + Preact + Material UI + material-table で作っている管理画面のビルドツールを Rollup から esbuild に変えたお話です。 2021/01/07 追記 esbuild に新しく CSS ローダーやプラグイン機構が実装されたので紹介記事を書きました！ esbuild の機能が足りないならプラグインを自作すればいいじゃない https://www.kabuku.co.jp/developers/create-your-own-esbuild-plugin はじめに これまでの JavaScript ビルドツールと私 以前は私も定石通り「アプリには webpack、ライブラリには Rollup」をビルドに利用していましたが、近年はアプリのビルドにも Rollup を利用することが多くなり、 webpack を利用することはな
Slackのチャンネルをprefixでまとめてくれる拡張を作りました！
チャンネルが増えすぎて目が辛いので、いい感じにまとめてくれる拡張を作りました！ これが こうなります インストールはこちら Chrome: Slack Channels Grouping - Chrome ウェブストア Firefox: Slack Channels Grouping – 🦊 Firefox (ja) 向け拡張機能を入手 Opera: Slack Channels Grouping extension - Opera add-ons Edge: Slack Channels Grouping – Microsoft Edge Addons 特徴 ハイフンやアンダースコアで区切られたものをまとめます。 chat-犬 chat_猫 DOMの更新を監視しているので、チャンネル作成や名前変更などにも対応しています。 タブが非アクティブな場合はDOMの監視は止めています。 経緯 チ
JavaScriptライブラリを読むときのコツ
少し前からライブラリを読むトレーニングを始めたのですが、最近ようやく読み方がわかってきたので、やり始めた頃に知っておきたかったことをまとめます。 これから JavaScript/TypeScript で書かれたライブラリを読んでみようと思っている方の助けになれば嬉しいです。 「私はこういう道具を使ったり、こういう工夫をしています」みたいな感じの内容ですので、もし「もっといい読み方があるよ」みたいなのがありましたらIssueなどで教えていただきたいです。 （※ライブラリを読むにあたって、ブラウザの話と NodeJS の話があるのですが、似てる点がほとんどなのでごった煮します。） エントリポイントを探す ライブラリを読むにあたって そのライブラリが持つ module がどう協調して全体が作られるのか その関数は正確にはどういう挙動をするのか などを考えると、ユーザーから渡された入力や呼び出しが
webpackの次のバージョンで入るassetModulesの紹介 - hiroppy's site
この機能が導入されることにより、{raw/file/url}-loader が不要となります。 webpack@4 でも使えますが、まだ実験的フェーズです。 Documentation Asset Modules | webpack webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, ... モジュールタイプと以前との対応表 asset/resource -> file-loader asset/inline -> url-loader asset/source -> raw-loader asset -> asset/resourceとasset/inlineを自動選択する(閾値: 8kb) 使い方 実験フラグをオンにする。 // webpa
Closure LibraryからTypeScriptの型定義を生成する - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドチームエキスパートチームの穴井(@pirosikick)です。 弊社の製品である kintone は Closure Tools (Closure Library と Closure Compiler の総称) を使って開発していますが、TypeScript を使ったモダンなスタックへの移行を検討しています。 その移行の過程で Closure Tools 側のコードを TypeScript で型安全に再利用したいケースが発生し、その解決策として Clutz というツールを試しています。 今回は、この Clutz がどういったツールなのか、その使用方法と注意点などについて紹介します。 この記事は次の条件に当てはまる方には特におすすめできる内容になっています。 Closure Tools(Closure Compiler, Closure Library)を使って開発
2019年版: 脱Babel!フロント/JS開発をTypeScriptに移行するための環境整備マニュアル - Qiita
TL;DR いろいろ書いていますが、一番書きたかったのは最初のライブラリと最後のReact Componentのプロジェクトの作り方ですね。ぱっとnpm installして、最初から型定義ファイルが入っていて、@typesを持っているライブラリを探したり、自分で.d.tsを書いたりしなくてもいい世界がやってきて欲しいな、という気持ちから書いています。 ここで紹介したTypeScript環境構築はすべて、自分用にYeomanのテンプレートとして作成したので、以下のジェネレータをインストールして選択したらそれでおしまいです。 @shibukawa/typescript (npmには公開していないので、checkoutしてビルドしてインストールしてください) 2020/7/26: React周りを現在の最新の情報に更新 2019/1/22: TSLint→ESLintに修正 2019/8/1:
Vuexによる状態管理を含む最高に快適な Vue.js + TypeScript の開発環境を目指す話 - Qiita
追記 2019/12/05 Vue 3.0 のリリースが現実的に近づいてきて色々と事情が変わっているので、話半分に聞いておいてください。 はじめに Patreon での支援募集をはじめました。この記事が良かった！という方は、今後の情報発信のためにもぜひぜひ支援お願いします。 https://www.patreon.com/potato4d Vue.js Advent Calendar 2018 年の管理役の potato4d です。昨年に引き続き、今年も Vue.js のアドベントカレンダーは他にもたくさんあるので、ぜひ #1 から追ってみてください。 12日目の今日は、 Vue.js + TypeScript での理想的な開発環境について考えてみたいと思います。 Vue.js における TypeScript 利用はまだまだ課題が多く、型の恩恵をうけるためのテクニックも複数存在しています。
webpack -> FuseBox 移行メモ - Qiita
webpackを使っていたプロジェクトをFuseBoxに移行してみました。 バンドル時間が超速くなり、バンドルファイルサイズが超小さくなりました。 webpack FuseBox package.json package.jsonの比較です。 "devDependencies": { "babel-cli": "^6.26.0", "babel-core": "^6.23.1", "babel-eslint": "^8.0.0", "babel-loader": "^7.1.2", "babel-preset-es2015": "^6.22.0", "babel-preset-flow": "^6.23.0", "babel-preset-react": "^6.23.0", "css-loader": "^0.28.7", "eslint": "^4.6.1", "eslint-load
JavaScriptフレームワーク選定の議論 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 相談内容 既存の管理ツールを新しく作り直すために新しいJSフレームワーク/言語使いたいのですが、何を選んだらよいでしょうか？ ここで選んだものは今後新しく作る時にも使用していく予定のため、学習コストよりメンテナンスしやすいものを選びたいと考えています。 利用者は社内外で特定の権限を持った人のみであるため、サーバサイドレンダリングはしない予定です。 言語は型があるものを利用したいのですが、TypeScriptとFlowのどちらがよろしいでしょうか？ 時間に余裕があれば、テストフレームワークやビルドツールについてもお聞きしたいです。 現在の
続 2017年1番人気はBabelかTypeScriptかそれともCoffeeScriptなのか？ - Qiita
以前、本当に2016年1番人気はTypeScriptなのか？ - Qiita を書きましたが未だにこの記事が共有されているようです。 この記事は最終更新日から1年以上が経過しています。が見えないのかあんたたちは。タイトルにも2016年と書いてあろうが あの記事見てなんだCoffeeScript使われてんじゃんと思われるのは、よろしくないので2017年度版を更新することにします。 ダウンロード数の比較です。 typescript vs babel-core vs coffee-script - npm trends Babelが頭ひとつ抜けましたね。 TypeScriptも順調に増加しているようです。 おまけ いくつか比較されやすいものも列挙しときます。 gulp vs grunt vs webpack vs browserify vs rollup - npm trends これがいいこと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Nondestructive_TypeScript.md