jsconf.eu 2019 に行ってきました。 特に npm や yarn の今後の話とそもそも Registry をどうしていくか、の話があったのでお知らせします。 そもそも Registry をどうしていくかについては次のエントリで話します。 tink: A Next Generation Package Manager npm の次のコマンドラインツールである tink が紹介されていました。 github.com presentation: github.com video: www.youtube.com そもそも npm の仕組み ローカル依存ファイルを読む (package.json, package-lock.json, shrinkwrap.json) 存在しないパッケージのメタデータをfetchする 木構造を計算して、実行する（npm v3 以降だとflattenする
どうも！大阪オフィスの西村祐二です。 バグを修正したり、機能を追加したりなど日々開発してリリース作業をしていると「CHANGELOG.md」を自動生成、自動更新したり、セマンティックバージョニングでタグを生成する仕組みがほしくなってきました。 いろいろ調べていると「ngx-semantic-version」がコマンド一発で「CHANGELOG.md」の自動生成環境を作ってくれて便利だったので紹介したいと思います。 「ngx-semantic-version」とは リリース作業時によくやるCHANGELOG.mdの更新や、Gitタグを付与する作業などを自動化する環境を構築してくれるライブラリです。 「ngx-semantic-version」を使うと下記のライブラリをいい感じにインストールして環境を作ってくれます。 commitlint Gitのコミットメッセージを規約に従ってるかチェックす
経産省発の npm モジュール！住所や電話番号の正規化、ジオコーディングなどができる IMI コンポーネントツールを試した！ Code for Japan の関さんが SNS でシェアしてて知ったのですが、経産省さんがなにやらオープンソースで住所や電話番号の正規化などなどをするツールを公開したとのこと。 https://info.gbiz.go.jp/tools/imi_tools/ 経産省が住所変換や法人種別名、電話番号の正規化に使えるIMIコンポーネントツールを公開しました。 ソースコードも公開。README にも使い方が丁寧に書かれていました。https://t.co/fPbV00EgZP 素晴らしい動き。こういう... #NewsPicks https://t.co/bew0qGKMFE — Hal Seki (@hal_sk) May 28, 2020 ぶっちゃけ当初はあまり期待
npmにモジュールを公開することは多くなってると思いますが、今までのnpmだと名前は早い者勝ちでした。 最近npm Private Modulesというprivateで扱えるモジュールを有料でサポートしましたが、これはscoped modulesをprivateで扱う時だけ有料でpublicで公開する時は無料で行えます。 scoped modulesというのは、@username/project-name という感じで、@ユーザー名がパッケージ名に入るので異なるユーザー間では重複しません。 The npm Blog — solving npm’s hard problem: naming packages 公開手順 実際にscoped modulesをpublicに公開する手順としては、 npm init --scope=<npmユーザ名> パッケージの名前が@<npmユーザ名>/パッケー
npmとはNode.jsインストール時に付属するパッケージマネージャーで、Node.jsのパッケージの管理や実行を取り扱うものです。 npmのバージョン5.2.0で導入された「npx」を用いると、下記のようにローカルにインストールしたnpmパッケージを、npxコマンドだけで実行できるようになります。 npxはnpmにバンドルされているため、npxの個別インストールは不要です。 次のようにしてモジュールを実行できます。 従来のnpmの実行方法との比較 従来では、ローカルのnpmパッケージを使用するには、次のような方法が必要でした。 方法1: ./node_modules/.bin/(パッケージ名)で実行する 方法2: $(npm bin)/(パッケージ名)で実行する 方法3: package.jsonにnpm-scriptsを記述して実行する npxはいずれの方法よりも簡潔なコマンドで、パッ
バージョン指定でいっつもこいつの違いを忘れてしまって、npm とか semver のドキュメントを探すところから始まるから自分用のメモ。 ^1.1.2 = 1.x ~1.1.2 = 1.1.x (追記 一応↑は間違っていないのだけど、厳密にいうとちょっと間違っていた) チルダ表記 ~ "明記したところ以下のバージョンがあがることのみ許容" ~1.1.2 = 1.1.2 <= version < 1.2.0 ~1.1 = 1.1.x ~1 = 1.x オリジナルの定義は、 Allows patch-level changes if a minor version is specified on the comparator. Allows minor-level changes if not. キャレット表記 ^ "一番左側にある、ゼロでないバージョニングは変えない (それ以下があがることは
こんにちは みんなにdisられて久しいsprockets氏ですが、面白そうなコミットが入っていたので紹介します https://github.com/rails/sprockets/commit/6eac004a1567f70270606170f8a4d51d4e2fb3e8 どんなコミット？ sprocketsからnpmパッケージを利用するための機能が追加されました。 これにより、例えばこれまでjquery-railsなどjsをラップしたgemを用いていたものを、npmで管理できるようになります。 この変更は何が嬉しいの？ この変更により、npmの世界でjsライブラリを管理する道が整備されました。 なぜ道が整備されたことを強調するかと言いますと、別にこれまでもbrowserify-rails/webpack-railsなどを利用すれば同じことが出来たからです。 ただ、「Railsが公式に
rake --tasks (-T) のようにpackage.jsonのタスクを一覧で見たかったのですが 用意されていないと思い込んでしまい、じゃ作るかと思い立ってコードを書いてみました。 まずはnpm code reading bin/npm まずは実行ファイル。npm-cli.js を実行しているだけのようです。 // .nodebrew/current/bin/npm NPM_CLI_JS="$basedir/node_modules/npm/bin/npm-cli.js" "$NODE_EXE" "$NPM_CLI_JS" "$@" bin/npm-cli.js npm ライブラリを使用してコマンド実行しているようです。 //.nodebrew/node/v4.2.4/lib/node_modules/npm/bin/npm-cli.js var npm = require('../
Web フロントエンド開発において gulp は非常に便利だ。しかしあまりにも gulp に依存しすぎており、これなしで開発できるだろうか？という不安もある。というわけで gulp を利用せず package.json と npm だけで同等の機能を実現する方法を検討してみた。 2015/11/4 追記 babelify v7.2 を試すで babelyfy 7.2 ( とその中の Babel 6.x ) について調べ、npm-scripts の変更が必要なことを確認したので追記。また Windows 環境の動作検証をおこなったところ、最新の watchify なら -o オプションが通ることを確認できた。よって本記事の最後の課題が解決したことになる。 2015/9/23 追記 cpx と rimraf を試すの内容をファイル処理に反映して簡略化。 2015/9/15 修正 Stylus
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、freeeでフロントエンドエンジニアをしている @joe_re です。 freee Engineers Advent Calendar 2015の4日目を書きます。 僕からはfreeeで現在進行中の革命について、フロントエンドのビルドプロセスを中心に書こうと思います。 革命 ってなんのこと？ というのはフロントエンドヤンキーこと @ymrl が 2日目で書いたので詳しくはそちらをご参照頂ければ幸いです。 背景 弊社ではRuby on Railsを主軸にしてWebサービスを作っています。 Railsは素晴らしいフレームワークで
JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも
npmに登録されているパッケージ数は10万、月間ダウンロード数も5億を超えました。7月の段階で月間3億程度ですから、こちらのグラフで見てもわかるように、かなり成長が加速してきていますね。 EdgeConf4において、パッケージ管理をテーマにしたディスカッションに、npmのCTOであるLaurie Vossと、npmのpeer dependencyをつくったGoogle Chrome TeamのDomenic Denicola（ES6のPromiseの取組みでも知られた人ですね。）が参加しています。この二人と、BowerのJosh Peekを中心に議論が進んでいます。ちなみにJoshはGitHubの社員で、最近では、左右に並べてdiffを比較できる便利な機能をつくった人でもあります。 「サーバサイドのパッケージマネジャとしては、CPANやRubygem、npmのように開発言語ごとにプレーヤー
タスク管理 package.json にはパッケージの依存を書いて npm install するのが基本だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、
スライド 当記事は以前勉強会でLTしたものです。 スライドは下記にあります。 フロントエンド覚えること多すぎ問題 モダンなフロントエンド開発で、入門記事を探そうとすると、 まずwebpackやTypeScript, Babelによるビルド環境構築から始まる記事が多くヒットします。 ですが、Node.jsの初心者がいきなり複数のツールを習得しようとすることが 挫折の原因になっていると感じています。 ですので、まずNode.jsをインストールした直後から、必ず使うことになる、 npmの機能をまず覚えておきましょう。 フロントエンド開発で覚えるべき３つのコマンド 以下の3つだけ覚えておきましょう。 npm init npm install npm run これだけ覚えれば、ひとまずフロントエンド開発を進めることができます。 完璧なワークフローを構築するのは、書いているアプリが大きくなってきてから
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
