package.jsonにfilesを書かないあなたは、誰かを少しだけ不幸にしています - Qiita
先に結論だけ package.jsonにfilesフィールドを指定すると、node_modulesに保存されるファイルサイズが減ります。 はじめに この記事は、npmのpackage.jsonに指定するフィールド、filesの指定方法と効用を解説、共有するためのものです。 想定する読者 この記事は、以下の読者を想定して書かれています。 JavaScriptの開発経験がある npmを使ったことがある npmやGitHubでnpmモジュールを公開している 想定する環境 この記事は、以下の環境を想定して書かれています。記事を読む前に、お手元の環境をご確認ください。 filesフィールドとは filesフィールドとは、package.jsonファイル内の設定フィールドです。このフィールドはnpmパッケージがインストールされたとき、どのファイルをnode_modulesにコピーするかを設定します。
package.json のチルダ(~) とキャレット(^) - Qiita
バージョン指定でいっつもこいつの違いを忘れてしまって、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. キャレット表記 ^ "一番左側にある、ゼロでないバージョニングは変えない (それ以下があがることは
Minimal Blog
宣伝: YouTubeで初心者向けの配信をしています。よかったら覗いていってね😉 概要あなたは普段、何気なく npm install を使っていることでしょう。 しかし、 npm install が何をしているのか、実は誤解している人も多いと思います。 記事のタイトルは釣りではないので、どんな時に npm install は問題を起こすのか、説明できない人は以下を読み進めてください。これは多くの開発者が無意識に無視している、とても重要な事項だと思っています。 なお、npm 4.x系以下の方は本記事の対象ではありません。 追記: 強めに書きすぎて誤解を招く部分があったので何度か修正しています。 参考資料:npm installnpm ci npm はパッケージマネージャです。パッケージマネージャは、開発に必要なパッケージ（ライブラリとか、プラグインとか色々）を管理するためのツールです。全て
脆弱性の警告を受けたnpmパッケージの依存関係を力技で直す - Qiita
概要 2018年4月にnpm v6.0.0がリリースされ、セキュリティチェックができるコマンドnpm auditが追加されました。 さらに2018年5月にはnpm6.1.0がリリースされ、セキュリティチェックに追加して脆弱性のある箇所を自動修正してくれるサブコマンドnpm audit fixが追加されました。 この機能は非常に便利で、node_modulesに存在する大抵の脆弱性を自動修正してくれます。しかし、パッケージの依存関係によって自動で直しきれない脆弱性が残ってしまうことがあり、現時点ではこれを手動で解消しなくてはいけません。その方法を共有します。 実践 まずは$npm audit まずは任意のプロジェクトでnpm auditをポチッと実行します。 $ npm audit //中略。ここに脆弱性のあるパッケージ一覧が表示されます found 25 vulnerabilities (
npm package.json 日本語版 取扱説明書
本ページは npm.org 提供文書を翻訳したものです。 原文は 本家参照 、誤謬・誤記の指摘は こちら からお願いします。 × npm package.json 取扱説明書 記述方法 このドキュメントを通じて、あなたの package.json に必要な全てを 学ぶことが出来ます。記述は JavaScript のオブジェクトリテラルではなく、 正しい JSON でなければなりません。 このドキュメントの多くの振る舞いは npm-config(7) に書かれている設定に影響を受けています。 name package.json の中で最も大事な項目は "name"(名前) と "version"(バージョン) です。必須であり、パッケージはこれらなしで インストール出来ません。name と version をもってして、パッケージが 完全に一意となることが想定されています。よってパッケージ内
npm installしたパッケージの更新確認とアップデート(npm-check-updates) - dackdive's blog
タイトルの通り。 npm install --save なり --save-dev なりして package.json に書き込まれたパッケージのバージョン、どうやって定期的にアップデートしていけばいいかわからなかったので。 新しいバージョンがリリースされているかどうかの確認と、実際にどのように新しいバージョンにアップデートすればいいのか調べてみた。 今回サンプルに使う package.json package.json の例として、以前、React のチュートリアルをやったときのリポジトリを使う。 { "name": "react-es6-tutorial", "version": "1.0.0", "description": "React Tutorial written in ES6", "main": "index.js", "scripts": { "test": "echo
ESLint 最初の一歩
We're excited to announce that ESLint v6.0.0 has been released: https://t.co/EO4ZrZIMYM — ESLint (@geteslint) 2019年6月22日 ESLint は JavaScript のための静的検証ツールです。コードを実行する前に明らかなバグを見つけたり、括弧やスペースの使い方などのスタイルを統一したりするのに役立ちます。同様のツールとしては JSLint, JSHint 等があります。 ESLint の特色は、 すべての検証ルールを自由に on/off できる 自分のプロジェクトに合わせたカスタムルールを簡単に作れる 豊富なビルトイン ルール (5.0.0 時点で 260 個) に加えて、たくさんのプラグインが公開されている ECMAScript 2015 (ES6), 2016, 201
npm linkを削除する - The Round
注：古い記事の為、内容が最新ではない可能性がありますm(＿ ＿)m npm linkでグローバルに作成されたシンボリックリンクを削除する方法。 マツウラです。 Yeomanではジェネレータを作成して動作確認をする際、npm linkを行いシンボリックリンクを作成します。 いくつかジェネレータを作成してゆくと初期にテスト目的で作成したもの、要らなくなったものが残ってしまいます。 npm -g lsで確認した際に、残っており気になったので調べました。 削除する方法についてメモしておきます。 npm linkでグローバルに作成されたシンボリックリンクを削除する方法。 sudo npm unlink -g <package_name> これだけです。簡単ですね。
npm ciを使おう あるいはより速く - Qiita
人類はより高速にCIを回していくべきだと思っている りんご（@mstssk）です。 先日、 npm の v5.7がリリースされ npm ci というサブコマンドが新たに追加されました。 The npm Blog — Introducing npm ci for faster, more reliable... http://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable CI/CDを開発プロセスに組み込んでいる場合により整合性があり高速なエクスペリエンスを提供する、と公式ブログでは紹介しています。 npm ci は何をするのか npm ci を実行すると常に package-lock.json から依存関係をインストールします。 既に node_modules フォルダの中身があっても
npm linkの基本的な使い方まとめ - Qiita
はじめに 仕事でnpm link機能をいろいろ試しながら導入したので備忘録も兼ねつつ、まとめます。 リンクを貼る 基本的には公式ドキュメントにあるとおりですが、実際に試した結果としてまとめます。 想定としては、 「use-npm-link-Aから、まだnpmに公開していないuse-npm-link-Bとuse-npm-link-Cにリンクを貼って動作を調べたい」 といった感じです。実際にリンクを貼った状態が以下の図です。 リンクしたいuse-npm-link-Bとuse-npm-link-Cは以下の図のようになっています。 ディレクトリ名 -> use-npm-link-B package.jsonのnameで指定された名前 -> use-npm-link-B ディレクトリ名 -> UseNpmLinkC package.jsonのnameで指定された名前 -> use-npm-link-
npmで名前空間を持ったモジュールを公開する方法(scoped modules)
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ユーザ名>/パッケー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
