JavaScriptのnew URL()には気をつけろ
概要 new URL("") で独自のスキーマを扱う際には要注意 Chrome, Firefox, Edgeあたりは他と異なる挙動を示すぞ！ 実装の違う何かでPlaygroundするような愚を犯すべからず 背景 URLPatternなんてイカしたものを見つけてしまった。 URLのマッチングと、パス引数の解析をやってくれるらしい。 おいおいその辺のFWがあっちこっちで再開発していたアレが、Web APIの標準実装に載るのか！？ どこでも簡易ルーター作れて捗るんじゃないのォ！？とDenoでいじってみた。 某Vimプラグイン用に独自のスキーマを定義し、その処理をパスに従ってさばくルーターを書いてみようと思ったのだ。 ここでは皆さんの馴染みのある（？）スキーマとして、 git:// を使ったとして読んでもらおう。 過ち 何をどうひっくり返したらそういうことが思いつくのか自分でも良くわからん。 初手
yarn v3 の独自機能を避けつつ yarn v1 から v3 へのアップグレードをする
yarn v3 が出ました。詳しい解説は譲るとして、esbuild integration や パフォーマンス向上が目玉です。 Yarn 3.0 🚀🤖 Performances, ESBuild, Better Patches, ... - DEV Community 流石に v1 はもう古いが、 v2 からの独自路線は受け付けがたい…という立場なのですが(yarn オリジナル作者の sebmck も難色を示しています)、今回は yarn 特有の機能をできるだけ避けて、できるだけ npm や pnpm 等と互換な部分だけで yarn v3 を使います。なので pnp も使いません。eslint や vscode の typescript 等でハマりどころが多すぎます。 ゼロインストールも否定派です。git blob objects のサイズが爆発して仕事にならなくなったことがあります。
CoffeeScript 辞めました - クラウドワークス エンジニアブログ
CoffeeScript 辞めました はじめに こんにちは、CrowdWorks のジャンヌチームのエンジニア bugfire です。 CrowdWorks は歴史のあるサービスで CoffeeScript が利用されている箇所が大量にあります。 具体的には411ファイルありました。1 いまとなっては CoffeeScript を利用したコードを新たに書くことも少なくなり、改善するときに TypeScript で書き直されることも多くなってきました。しかし、個別に変換すると時間が掛かってしまうため、まとめて機械的に変換することにしました！ 3行まとめ CoffeeScript より TypeScript の方に記述を移していきたい。 利用している Sprockets の CoffeeScript 変換コードを借用して全ファイルを変換しました。 確認は変換前後の出力 JavaScript コ
Typicode's blog - Husky 5
I’m happy to announce the release of husky 5 🎉 🐺 woof! During the past years, husky has grown in complexity. With this version, I wanted to go back to something simpler, more flexible and closer to the metal. You can use husky 5 in your Open Source projects today. Thanks for your support and feedback. I hope you’ll enjoy this release <3 https://github.com/typicode/husky Faster and smallerHusky 5
git-secretsとhuskyを同時に使用する
はじめに 機密情報をコミットしないようにgit-secretsの設定をしようとしたところ、既にprecommit用のNode.jsライブラリhuskyがインストールされていたため、コンフリクトしてgit-secretsの設定ができませんでした。 どっちとも使いたかったので、それぞれ動くように工夫してみました。 2019/07/10 追記 会社の @aki77 さんが、もっと良い方法を見つけてくれたので、 そっちを「方法1」として追記しました！ 方法1: husky内でgit-secretsを呼び出す gitのhooks内では、デフォルトのままhuskyだけが呼ばれるようにしておき、 huskyでのチェック項目の1つとして、git-secretsを呼び出します。 lint-stagedも併用します。 git-secretsをグローバルにインストール
初学者向けpackage.jsonハンズオン - Qiita
Node.js初学者向けにpackage.jsonハンズオンを実施しましたので、その時に作ったハンズオン資料を公開します。 npmコマンドやpackage.jsonに慣れることが目的のハンズオンの資料ですので、Node.jsとは何か？といった説明はしません。ご了承ください。 文章の手順通りに進めていけば、npmコマンドやpackage.json編集が体験できます！ 事前準備 Node.jsのインストール 事前にNode.jsのインストールをお願いします。（すでにNode.jsがインストール済の方は飛ばしてください。） Windowsの場合 Windowsの方は、こちらの記事をご参照ください。Chocolatey > Nodist > Node.jsの順番でインストールします。 Windowsで、Chocolateyとnodistで、バージョン切り替え可能なNode.jsの環境を構築する M
GitHub Actionsにreviewdogを飼ってみた！(eslint編) | DevelopersIO
はじめに 最近GitHub Actionsの記事をよく見かけるので、試してみることにしました。 本稿は、GitHub Actionsにreviewdogを連携させた記事となります。 reviewdogとは 各種linterの実行結果をプルリクエストのコメントで指摘してくれます。 詳細な説明は作者様の記事を参照するのが良いです。 Reviewdog を飼ってコードレビューや開発を改善しませんか reviewdogは、GitHub Actionsに対応しており、GitHub Actionsのusesで指定できるコードが用意されております。 詳細は、Pubilc Reviewdog GitHub Actionsを参照してください。今回はreviewdog/action-eslintを活用します。 用意するサンプル 用意したリポジトリは以下のようなプロジェクトです reactプロジェクト git
husky + lint-staged で品質を保つ - ナデズダ・ゴボリン🖥
リントツールをインストールしても使わなければ意味がない。 というわけで人的なリント忘れを未然に防ぐためにも、huskey と lint-staged と 各種リントツールを組み合わせてコミット前に自動的にリントが行われる環境を作りましょう。リントエラー時にコミットを弾くことによって git 上のコードの品質を保つことができます。 環境 husky 1.1.0 lint-staged 7.3.0 git hooks の設定を package.json などからできるようにしてくれるツールです。 生の git hooks だとチーム内で共有とかがしにくいですが、husky を使って設定を package.json などに書けば簡単に共有できます。 pre-commit フックを使うことが多いと思いますが、クライアントサイドのフックであればすべてサポートしているみたいです。 ステージングしたファ
[メモ] JavaScriptエンジンを作る話 - Qiita
Rapidusの進捗を記していく。逐次更新 どんなJSエンジンを目指してるのか 自作ブラウザ(Naglfar)に組み込めるようなもの ↑でも当分はNodeJSみたいなのを目指すと思う (それ単体で使えるような物、という意味) JITに対応し、速い (LLVM使う?) 8/11追記: Tracing JITが部分的に動いた 課題 グローバル変数の呼び出し、遅い ネストした関数、実装してない 実装しました VMとVMのコード生成に関するコードのテストを書いてない (最近書き始めた) よく考えたら、字句解析器がコメントに対応してない 対応 参照渡しできない 進捗 日数は、Gitでコミットした日を数えてます。(7/1 7/2 7/5 とコミットしていたら、7/5は3日目としてカウント) 1日目 字句解析器がほぼ完成
![[メモ] JavaScriptエンジンを作る話 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/182b3444b371ff8eff3efe9e5265881c60c3f401/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUUzJTgzJUExJUUzJTgzJUEyJTVEJTIwSmF2YVNjcmlwdCVFMyU4MiVBOCVFMyU4MyVCMyVFMyU4MiVCOCVFMyU4MyVCMyVFMyU4MiU5MiVFNCVCRCU5QyVFMyU4MiU4QiVFOCVBOSVCMSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9M2E3MjFiZGYxMDcyOTIzOTFmYWI0ZjRjYTI3NmNjYzE%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwdWludDI1Nl90JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0yMDc3OTllYjc5NGI1MGZmYmYwYjE3YTJlYjQzMjYzMA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3De742d1bc30e946b57917cde2da51b794)
npmにライブラリをアップロードするときに.npmignoreで生成物を公開/制限するパターン - Qiita
やっと理解したのでメモ 何がしたいか npmパッケージを登録する時にcoffeeやtypescriptのコードをコミットせず生成したjsだけをアップロードしたい 自動生成したjsをgitで管理したくない どうやるか src/** にソース、lib/** に実体があるとする .npmignore に npm にアップロードしたくないものを書く
コスパで学ぶ自動テストのはじめ方 - 若くない何かの悩み
Qiita 週間ランキング1位を獲得しました Kuniwak です。ご愛顧ありがとうございます。 qiita.com さて、本題に移りたいと思います。 つい最近ですが、勤め先の別チームに向けて自動テストの導入を支援するための資料を作成しておりました。こちらを共有したいと思います。 speakerdeck.com 資料中にある「仕様化テストを推奨しない」という決断には賛否両論あるかと思います。仕様化テストを推奨しなかった理由は、仕様化テストにかかるコストは相当に高く、本当に余裕があるときでないと選べない選択肢だったからです。今回自動テストを導入しようとしているチームは、見るからに余裕のない状況だったので仕様化テストからやれとは言えませんでした。 もし、「自分だったらこうする」等のアドバイスがあれば、ぜひ参考にしたいと思います。コメントなどに書いていただけると嬉しいです。
thank-you-starsで利用しているnpmパッケージに気軽にスターを送る - teppeis blog
先週、こういうツイートを見て、 OSSを使っているなら、GitHubのリポジトリにそっとスターをつけると開発者のキャリアにわりと直接的に貢献できるのでお薦めです。少額の寄付より効果があるかも— Taro L. Saito (@taroleo) 2017年8月15日 共感したのでサクッと作った。 github.com package.jsonと同じディレクトリで実行するだけで、depsとdevDepsのパッケージのGitHubリポジトリにスターできる。 事前にパーソナルトークンをホームディレクトリに保存しておく必要があるけど、その辺はREADMEを読んでくれ。 依存に入れて使っているということは、それなりに恩恵を受けているということなので、問答無用でスターを送ってしまって良いと思う。 孫依存のパッケージにも送るか迷ったけど、npm的にそこ含めると一気に数が膨れてしまうのでやめた。 これでみん
Gitのコミットグラフを可視化できるGitGraph.jsがおもしろい - Qiita
プレゼン資料を作っている時に「このコミットグラフをMarkdownかテキストで書けたらな」と思ったことがある人、結構いるのではないでしょうか。 GitGraph.js を使うと、JavaScriptで記述したコミットログをcanvasを使って可視化できることを知りました。なかなかおもしろいです。 準備 まず GitGraph.js の JavaScript と CSS ファイルを読み込みます。GitHub からソースをcloneするなり、bowerを使うなり、CDNを使うなり、お好みで。ここではコミットグラフを定義するコードも別ファイル index.js に書くことにします。 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>GitGraph.js</title> <link rel="stylesheet" type=
npm dependenciesを更新してGitHub Compare Viewのリンク付きでPRするツールを定期実行する - Islands in the byte stream
タイトルに要素を詰め込みすぎましたが、要は CircleCIを使ってbundle updateを定期実行する - Qiita の npm update 版です。web appのJavaScriptライブラリ管理にnpmを使うとき、依存関係のアップデートを継続的に行うためのツールです。 https://github.com/bitjourney/ci-npm-update これはいまのところGitHub専用です*1。CIサービスはドッグフーディングも兼ねてCircle CI用の起動スクリプトを同梱してますが、実際には ci-npm-update を定期実行するだけなので簡単に代替可能です。 これはCircle CI + Heroku Schedulerで動かしていて、以下のようなフローです。Circle CIはJenkins含め他のCIでも動かせますし、Heroku Schedulerはcr
Lerna を使って、 Babel や React が採用している monorepo を試してみる - Qiita
monorepo とは 複数の npm package を 単一の git repository で管理すること 例えば Babel では、 100 以上の npm package が単一の git repository で管理されている https://github.com/babel/babel/tree/master/packages package 毎に repository を作る場合と比較した Pros & Cons Babel の repository のドキュメントから抜粋 Pros: lint, build, test, release のプロセスを共通化できる package をまたがった修正が容易になる issue 管理を一元化できる 開発環境の構築が簡単になる テストも package をまたいで実行でき、複数 package が絡む不具合の検知が容易になる Con
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - ai/nanoid: A tiny (124 bytes), secure, URL-friendly, unique string ID generator for JavaScript
GitHub - colinhacks/zod: TypeScript-first schema validation with static type inference
npmのprivate registryからGitHub Packages Registryに移行する
開発環境構築に時間をかけない
GitHub - lerna/lerna: :dragon: Lerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.
