textlintのコアをTypeScriptで書き直した、textlintの今後について
textlint 9.0.0をリリースしました。 textlint 9.0.0では@textlint/kernelという内部的に使うコアモジュールをTypeScriptで書き直したバージョンが使われています。 元々textlintはNode.jsで動くように作られたため、fsモジュールなどNode.jsに依存しています。 そのため、ブラウザなどで動かす場合などはビルド時に色々工夫しないと動きません。 文書校正ツール textlint の Chrome 拡張を作った - もなでぃっく LocalStorageで誰でも安全にMarkdownでスライドやメモ作れるサービス作ったよ この問題をどうにかするためには、textlintというモジュールからロジックやLint処理部分だけをNode.jsなどに依存しない純粋なJavaScriptとして切り出す必要があります。 アドホックに対応するならブラウ
Using Scala.js With NPM And Browserify | Toptal®
Today, writing applications in languages that compile to JavaScript is a very common practice. Scala developers, for example, can use Scala.js and have the same language for both the server and the client. That said, Scala’s compiler and standard dependency management tools are too limiting in the modern JavaScript world. In this article, Toptal Freelance Software Engineer Michele Sciabarra shows
JavaScriptライブラリ/プロジェクトのファイルサイズの問題点を見つける方法 - Qiita
ブラウザ向けのJavaScriptだとファイルサイズはある程度気になると思います。 この記事では、ファイルサイズの計測方法やボトルネックとなってるライブラリの見つけ方についてできるだけ簡単な方法をまとめます。 ファイルサイズと一言にいっても、ブラウザでは大体minifyしてから配布するのでminify後のファイルサイズも重要です。 ソースコード自体のファイルサイズ minifyしたファイルサイズ minify + gzipしたファイルサイズ コメントの多いソースコードはminifyするとかなり小さくなったりすることが多いので、ソースコード自体のファイルサイズでは比較しにくいです。 また、ソースコードにおいて assert モジュールを使っているとファイルサイズが10kb弱程度minify後で変わります。 assertモジュールは通常外しても問題ないので、unassertでビルド時に取り除き
package.json の browser field 実践編 - Qiita
package.json の browser field 入門編 では、package.jsonのbrowser fieldの役割と機能について紹介しました。 本編では、この機能のbundlerごとの実装の違いと、それを回避する方法を説明します。 ここで取り上げる実装の違いとはずばりpathの解決方法です。 ./から記述するかどうか .jsを記述するかどうか mainとの対応関係 この3つの要素が絡んできます。 なお、パス解決のresolverを指定できる系もあるようですが、ここでは各々のbundlerがデフォルトで用意しているresolverについて論じています。 (なぜなら、resolverを外部が指定しなければ意図通りbundleされないというのは、利用者にとってはbundleされないのとほぼ同義です) 調査したbundlerは以下です。 browserify webpack Rea
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - vercel/hyper: A terminal built on web technologies
