Deno 2.0リリース ―大規模プロダクトにも対応可能なJavaScript環境へ | gihyo.jp
Deno Land Inc.は2024年10月9日、同社が開発するJavaScript/TypeScriptランタイム環境Denoの新バージョンDeno 2.0のリリースをアナウンスした。 Announcing Deno 2 4 years after Deno 1.0, the next generation of JavaScript is ready for production at scale. Deno 2 is out today: 🐢 Fully backwards compatible with Node and npm 📦 Package management and node_modules and package.json 📅 Long term supporthttps://t.co/LsV4D4Too8 pic.twitter.com/F6EI3whmX8
The massive bug at the heart of the npm ecosystem
Disclosure: I was the Staff Engineering Manager for the npm CLI team between July 2019 & December 2022. I was a part of the GitHub acquistion of npm inc. in 2020. I left GitHub, for various reasons, in December.tldr;a npm package's manifest is published independently from its tarballmanifests are never fully validated against the tarball's contentsthe ecosystem has broadly assumed the contents of
JSR: the JavaScript Registry
Introducing the JSR open governance boardJSR, a modern open source JavaScript registry, is meant for the greater JavaScript and TypeScript community. We're thrilled to announce its own independent governing body. Announcing OpenAI on JSROpenAI, leading development platform for building generative AI products and experiences, now has a JavaScript and TypeScript SDK on JSR. Announcing Growthbook on
colorsなどのnpmパッケージに悪意あるコードが含まれている問題について
追記: 2022年1月11日 2:29 JSTにDoS脆弱性としてセキュリティアドバイザーが出されて、悪意あるバージョン(1.4.1や1.4.2)はnpmからunpublishされ、npmの最新は安全なバージョンである1.4.0へと変更されました。 Infinite loop causing Denial of Service in colors · GHSA-5rqg-jm4f-cqx7 · GitHub Advisory Database 2022-01-08 に colors というnpmパッケージにDoS攻撃のコードが含まれたバージョンが1.4.44-liberty-2として公開されました。 GitHub: https://github.com/Marak/colors.js npm: https://www.npmjs.com/package/colors 問題についてのIssu
「オープンソース」は壊れている
christine.websiteのブログより。 または: お金を払わない限り、有用なソフトウェアを書かないのか? 最近、重要なJavaエコシステム・パッケージに大きな脆弱性が見つかりました。この脆弱性が完全に兵器化されると、攻撃者はLDAPサーバから取得した任意のコードを実行するよう、Javaサーバを強制することができます。 <マラ> もしこれがニュースで、あなたがJavaショップで働いているなら、残念ですが、あなたには2、3日が待っています。 私は、これが「オープンソース」ソフトウェアの主要なエコシステム問題の全ての完璧な縮図だと考えています。log4j2が、この問題の最悪のシナリオの1つの完璧な例であると思うので、このすべてについていくつか考えを持っています。この問題に関与したすべての人が、現実世界の問題に対する完全に妥当な解決策のためにこれらすべてを行ったことは完全に合理的であり、
‘-‘ という名前の、中身が無いのに70万回ダウンロードされてる謎のnpmパッケージ
– という名前の JavaScript/TypeScript パッケージについて警告を発している記事が話題となっています。 このパッケージ、中身はほとんど空で、Readme と、dev で TypeScript を動かせるようにするライブラリ群を呼ぶ箇所だけのもの。 しかし、この “-” を使っている他の npm パッケージが 50個以上あり、約一年前の公開時からのトータルのダウンロード数は72万回にもなります。 しかし、”-” を読み込んでいるパッケージを見てみても、”-” が必要そうには見えません。 警告記事では、この無名のパッケージが密かに使われるようになった原因が、npm コマンドのコマンドラインを打つときのミスタイプにあるのではないかとの仮説を立てています。 つまり、someFlag というオプションを使い npm i -someFlag somepackage と打つべきところ
JavaScript Registryの今後 - from scratch
さて、前回は tink と yarn v2 における CLI 戦略の話でした。次は JavaScript Registry についてです。 ちなみにこの内容が今回 JSConf.EU 2019 で一番盛り上がったトピックです。 JavaScript Registry とは JavaScript Package をバックエンドで管理しているサービスです。 npm が管理しているものがいちばん有名です。他にも GitHub が管理する Registry が公開される予定です。 The economics of Package Management the economics of package management slide: github.com video: www.youtube.com 「Package Managementの経済」というタイトルです。 聴講者からすると、何話すのか
フロントエンドの開発環境に Docker は不要(少なくともMacでは) - mizchi's blog
追記: 前提部分 開発環境を docker-compose で抽象することが最近のベストプラクティスだとされているが、フロントエンドをコンテナに突っ込むと無視できないIOボトルネックが発生する。 とくにwebpackのファイル監視からのビルドで発生する高頻度のIO処理を捌くために、フロントエンドだけはホスト環境に移したほうがいい、という主張。 これについて speakerdeck.com 自分の意見 Web開発者の主要な開発環境である Docker for Mac は I/O がとにかく遅い (3x~5x) data volume の driver やら cache を工夫しても遅い npm install/webpack は 基本的に I/O ヘヴィー とくに大規模開発時の watch => build がクリティカル webpack.conifg の entry で自分が関与する部分以
Node.js における設計ミス By Ryan Dahl - from scratch
Ryan Dahl は Node.js の original author ですが、彼の作ったプロダクト deno に関するトークが jsconf.eu 2018 でありました。 Node.js にずっと関わってきた僕が見て非常に興奮するような話だったので、しばらくぶりにブログに書き起こすことにしました。 背景 Ryan Dahl は2009年に Node.js の話を初めて公の場に公開しました。その時の「公の場」というのが「jsconf.eu 2009」です。 www.youtube.com Video: Node.js by Ryan Dahl - JSConf.eu - 2009 この発表から Node.js が広まり、今やサーバのみならず、IoTデバイス、デスクトップアプリなど、様々なところで動作しています。 で、今回はその発表から9年の歳月が経過し、Node.jsに対しての設計不
.mjs とは何か、またはモジュールベース JS とエコシステムの今後 | blog.jxck.io
Intro 長いこと議論になっていた ES Modules の Node における扱いに一応の決着が付き、 .mjs という拡張子が採択された。 この拡張子の意味と、今後ブラウザと合わせて Universal JS を実装していく上での作法が見えてきたことになる。 合わせてエコシステムが対応していくことで、長年の夢だった JS のモジュール化を進めていくことができるだろう。 ES Modules 徐々に揃いつつある ES Modules(ESM) の仕様は TC39 で行われており、その仕様については主に以下のような部分になる。 import や export と行った構文 module 内はデフォルト strict mode module でスコープを閉じる module 内の this は undefined etc 逆に以下は TC39 での策定範囲外となる どう Module を読
GitHub - yarnpkg/yarn: The 1.x line is frozen - features and bugfixes now happen on https://github.com/yarnpkg/berry
This repository holds the sources for Yarn 1.x (latest version at the time of this writing being 1.22). New releases (at this time the 3.2.3, although we're currently working on our next major) are tracked on the yarnpkg/berry repository, this one here being mostly kept for historical purposes and the occasional hotfix we publish to make the migration from 1.x to later releases easier. If you hit
npm、一見無意味なパッケージを消したら1000件ものパッケージが依存するパッケージであったことが判明
npm、一見無意味なパッケージを消したら1000件ものパッケージが依存するパッケージであったことが判明 npmが一見無意味に思えるfsというパッケージをSPAMとみなして削除したところ、1000件ほどのパッケージが依存するパッケージだったので、削除を取り消した。 npm, Inc. Status - "fs" unpublished and restored 今日、数分ほど、"fs"というパッケージが、ユーザーからSPAMであるという報告を受けて、レジストリから非公開にされた。これは現在復旧されている。これは私(@seldo)による人為的なミスである。私は非公開が安全であるかを確認する内部のガイドラインに従っていなかった。ビルドが阻害されたユーザーに謝罪する。 詳細："fs"というパッケージは、無意味なパッケージである。これは単に"I am fs"をログに残して終了する。このパッケージが何
Rebuild: 137: Tested In Production (naoya)
伊藤直也さんをゲストに迎えて、Kindle, フロントエンド開発、テスト、チームビルディングなどについて話しました。 Show Notes Amazon will announce a new Kindle next week LOGICOOL ワイヤレス ソーラーキーボード k760 液晶ディスプレイの「色温度」を究める Rebuild: 114: Rebuildersland (Shu Uesugi) Redux kik, left-pad, and npm Emails between kik and Azer isarray Plugins · Babel フロント界隈におけるJavaScript開発環境 npm@3 Flat Module Installation axios: Promise based HTTP client vue.js EmberConf 2016 Dan
npmからkikとその他諸々が消されたまとめ
npmとは、node.jsにおけるパッケージシステムのことだ。npmを使えば、他人の書いたnode.jsベースのプログラムとライブラリの入手と利用がとても簡単になる。 そのnpm界隈が混乱している。発端は以下のURLだ。 I’ve Just Liberated My Modules — Medium Azer Koçuluはkikという名前のnpmパッケージを公開していた。このkikというソフトウェアの中身についてはここでは関係がない。 さて、それとは別に、kik.comというスマフォ用のチャットアプリを出しているKik Interactive社がいて、kikという名前のパッケージをnpmで出したいので、名前を明け渡すように要求した。 Azerはこの要求を拒否した。すると、Kik Interactive社はnpmの管理者に片っ端からメールを投げまくり、そのうちの一人が反応して、Azerの意
依存するパッケージは厳選しよう - methaneのブログ
japan.zdnet.com JS界隈が大騒ぎになった事件だけど、こういった事件自体は完全に防ぐことは不可能だと思う。 今回は依存ライブラリが削除されるだけで済んだけど、 npm install するだけで ~/.ssh ディレクトリを zip にしてどこかに送信するような悪質な攻撃であれば、単にCIが止まるどころでなく、世界中のエンジニアの秘密鍵がばらまかれてあちこちのサーバーにssh可能な事態になったわけで、そんな悪質な攻撃を bugfix なマイクロバージョンアップとして公開される事もありえたわけだ。 第三者のパッケージに依存するということは、それだけのリスクを背負い込むということだ。だが、逆に外部のライブラリに依存しないようにすると、生産性が落ちてしまう。 なので、コードを読む、信頼できるメンテナの公開しているパッケージを選ぶなどといった方法で、リスクとメリットのバランスを取って
最近あまり使ってない、流行っていた時期もあるフロントエンドもの
最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
JavaScriptトレンド総括（2014）
はじめよう TypeScript - 入門から実践まで - 素の JavaScript とはさようなら!Jun-ichi Sakamoto
npm とフロントエンドのパッケージ管理の未来
JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも
browserify をはじめてみる
Browserify を触ってみたメモ。 Browserify とは CommonJS のモジュールの仕組み、つまり Node.js の require をブラウザ上でも使えるようにするもの、ということでいいみたい。Readme を読む限りは、npm にあるモジュールをブラウザ上にもっていくために作られ始めたような印象をうけるが、ちまたのエントリーをみていると AMD に代わりに CommonJS でフロントエンドの依存関係の管理をする (RequireJS ではなく、Node.js 感覚で require 関数をフロントエンドで使う) ためのツールとしても使っていいようだ。 やりたいこと 複数の js ファイルの依存関係を記述したい 最終的に、依存関係を考慮した順番で、ひとつの js ファイルに結合したい 作りたいのは第三者のサイトに埋め込んでもらうスクリプト (サードパーティスクリプト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2016/10/12/20161011facebook-partners-with-google-others-to-launch-a-new-javascript-package-manager/
