Webサービス開発でのmonorepo環境(Turborepo, nx)
Webサービス開発の文脈で、モノレポ環境を作る方法について整理しました。 ※バックエンドもフロントエンドも全てTypeScriptで開発している前提 この記事を書いた背景 世間で言われる「モノレポ」がどのように達成されているのか知らなかった 参考記事を読んでると実現方法が異なっていたり、運用のイメージが見えなかったり、ベストプラクティスが分かりづらかった Turborepoのようなモノレポツールを導入すれば解決しそうだが、このツールが何をしてくれるのか理解できなかった モノレポ何も分からない………になった この記事ではモノレポに関連する仕組みを1つ1つ丁寧に把握し、最終的に理想的なモノレポ環境を実現することを目指します。 モノレポとは？ まずは用語の整理から。 モノレポを素直に訳せば「1つのリポジトリ」という意味でしかなく、1つのリポジトリで開発していればそれは「モノレポ」と呼べそうです。
Vite 3 が採用した CJS Proxy による Dual Package 構成
2022 年現在、Node.js 界隈は ESM (ES Module) への移行の過渡期であり、特に既存プロジェクトにおいては CJS (CommonJS) 構成であることがまだまだ多い。また、Pure ESM な npm パッケージは、CSJ プロジェクトからの利便性が悪く、dynamic import が必須で非同期化を強いられたり TypeScript の設定変更が必要だったりと面倒が増える。 そんな状況のため、広く使われたい npm パッケージを公開する場合、importでもrequireでも利用できるよう dual package 構成を取りたくなるが、定番手法が確立しているとは言えず、意外と面倒が多い。よく見るのは、tscやesbuild等で ESM 用と CJS 用の設定ファイルを用意してそれぞれ別ディレクトリに出力し、パッケージに両方同梱して conditional ex
Makefileの代わりにnpm scripts+zxを使う - 詩と創作・思索のひろば
そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として Makefile を使いがち。 Pros make は事実上どんな環境にもあることを期待してよい シェルで実行されるコマンドをそのまま書ける タスクの依存関係が明示できる Cons make では positional arguments が使えない 少し複雑なことをしようとすると Makefile 専用の文法を覚える必要がある 現代では、ファイルベースのタスクの依存関係は make が発明されたころほどは必要ではない Docker とか Go とか Webpack がよしなにしてくれることが多い 例: docker compose のラッパー ちょっとしたコマンドのラッパーを書きたいことがある。Makefile を書きはじめたらすべてのエントリポイントを make にしたい。ということで、以下のような Make
💡 Node.jsのバージョン管理ツールを改めて選定する【2021年】 - Qiita
開発者「すみません、なんかnpm iとかnpxコマンドがうまくいかなくて…」 ワイ「でたー、cb.apply is not a functionって書いてません？」 開発者「書いてます」 ワイ「ちょっと見てみますね」 ワイ「……これはnpm入れなおしたほうが早そうですね…」 ｶﾀｶﾀ… ワイ（うーん…なぜ未だにnodistで消耗しているのか…😨） TL;DR nodistはもうやめよう 選定するときは、まず選定基準を決めよう 関連技術の特徴を洗い出そう それらが自分たちの環境にどれくらいマッチするかで比較しよう Windowsならfnmがオススメ1！ ※ バージョン管理ツールがなんだかわからない方は「Node.jsのバージョン管理ツールとは」からお読みください。 うわっ…私の現場、nodist使いすぎ…？ Node.jsの利用が本格化してきたころ、私の周りでは圧倒的にnodistが流行し
npm v7の主な変更点まとめ
こんにちは@watildeです。趣味でnpmへのコミットをたまにしているのですが、最近はNode.js側に比重を置いているのでv7のキャッチアップに少し遅れてしまいました。キャッチアップついでに自分なりに情報をまとめたので、v7における代表的な新機能と破壊的変更について、GitHubの記事よりも少し詳しめに紹介と解説を行ってみます。なるべく参考リンクを付けているので、詳細が気になった際はリンクから一次情報に飛んで読んでみてください。 また、情報に誤りがあった場合はTwitterにて教えていただけると助かります。 背景 npmチームより、2020/10/13にnpmの新しいメジャーアップデートであるところのv7の公式リリースが発表されました。8月からbeta版のリリースを繰り返していましたが、2ヶ月かけて内部的なリファクタリングとスモークテストを繰り返して今回の発表に至ったのかと思います。ま
Volta - The Hassle-Free JavaScript Tool Manager
⚡ Fast Install and run any JS tool quickly and seamlessly! Volta is built in Rust and ships as a snappy static binary. ⚡ Reliable Ensure everyone in your project has the same tools—without interfering with their workflow. ⚡ Universal No matter the package manager, Node runtime, or OS, one command is all you need: volta install.
モダンJavaScript概論 − Node, npm, ECMAScript, Babel, Webpack | Hypertext Candy
2020.04.30 モダンJavaScript概論 − Node, npm, ECMAScript, Babel, Webpack この記事では、モダンな JavaScript を書くための前提として知っておくべき、いくつかのキーワードを紹介します。想定読者は、初心者 〜 jQuery なら書けるレベルの開発者です。これから React や Vue.js を学びたい方、または Web 開発の世界に飛び込む新人さんなどの学習の助けになれば、と思います。 「モダン」な JavaScript ここで言う「モダン」とはどういう意味でしょうか？ 「モダン JavaScript」という表現は数年前から目にしますが、大抵 ES2015（JavaScript の 2015 年バージョン）以降の JavaScript を指しているようです。確かに、const / let やアロー関数などの文法的な改善、A
意外に知らないnpmと便利なCLI
Ehime.js #2の資料です。 https://ehimejs.connpass.com/event/153511/
複数のモジュール形式(CommonJS, ES Modules, UMD)をサポートしたnpmパッケージの作り方 in TypeScript - dackdive's blog
はじめに npmパッケージを開発するとき、パッケージ利用者の実行環境に合わせて適切なモジュール形式のファイルをパッケージに含め、提供する必要があります。 具体的には、たとえば以下のようなバリエーションが考えられます。 Node.js環境であれば CommonJS 形式 (module.exports / require() ) ブラウザ環境で、webpackやRollupなどのモジュールバンドラーを前提とするならば CommonJS や ES Modules 形式 (export / import ) ブラウザ環境で、モジュールバンドラーなどは使わず<script>タグでファイルを読み込んで利用するならば UMD 形式 このとき、パッケージ提供側はどういったファイルをパッケージに含めるべきなのか、またそれを TypeScript でどのように実現できるのかがあまりよくわかっていなかったので
知らないのは損！npmに同梱されているnpxがすごい便利なコマンドだった | DevelopersIO
Nodeのパッケージマネージャーであるnpmにはnpxというコマンドが同梱されています。これまであまり使ってこなかったのですが、調べてみたらとても便利なコマンドだったので使い方などをお届けします。 こんにちは。サービスグループの武田です。 Nodeは現代のフロントエンド開発にはなくてはならない存在となりました。またクラスメソッド社内で静かなブームとなっているAWS CDKでの開発もNodeを利用します。そのCDKプロジェクトのひな型を作成する際に、npxコマンドを使用している例をよく見かけたのですが、そういえばこのコマンドよく知らないな？ということで調べてみました。 検証環境 次の環境で検証しています。 $ sw_vers ProductName: Mac OS X ProductVersion: 10.14.5 BuildVersion: 18F132 $ node -v v10.16.
npm, yarn による zero install 戦略 - from scratch
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する
結局ライブラリはCDNから読み込むのとnpm installして自前配信のどっちが良いのか？(意見も求む) - Qiita
結局ライブラリはCDNから読み込むのとnpm installして自前配信のどっちが良いのか？(意見も求む)JavaScriptnpmTypeScriptCDNwebpack 執筆の動機 JavaScriptやらTypeScriptやらでコードを書いている際に、利用する各種ライブラリをCDNで読み込むこともnpm installしてからwebpackで固めて自前配信することも両方できることが多いと思うのだが、どちらを選択すべきなのだろう？ 昔はCDN最強説があったし、私もそれで納得していたが、ここ数年で状況が変わったように思う。とはいえ、人によって意見が異なる部分だと思うので、重要技術について触れながら私なりに考察する。 考慮する観点 ユーザーの実行速度(実行速度) ユーザーがWebページを訪問した際に、応答速度が遅いと逃げられてしまうだろう。お客さんがいないとサービスは成り立たない。重要な
ワイが個人的に便利だと思っていてよく使っているJavaScriptモジュール(npm)たち - Qiita
この記事はLIFULL Advent Calendar 2018の19日目の記事とされている恐れがあります 謝罪 wasmとSWとReactのフロント全部盛りマンやります 🙋 部署が代わり開発領域も変わってしまい、ジェイクエィリでDOM操作をし過ぎた反動でフロントに関する知識を忘却してしまいました。誠に申し訳ございません。 どアタマでの謝罪により万に一人に楽しみにされていた方がいらっしゃった時の可能性を潰しておきます。 ここから本題 ここ1年の中で しまくったgithubリポジトリを年末調整すると同時に、 使っていて個人的に便利だなと思っているものを簡単に紹介しようと思います。 React 魂のviewフレームワーク Facebook謹製 Redux Flux思想の状態管理ライブラリ React使うならだいたい使うはず storybook インタラクティブなUIコンポーネント(React
yarnチートシート - Qiita
webpackに引き続き、Railsが推してるフロントパッケージマネージャのyarnを調べてみました。npmも慣れてきたんで変えるのやだなー、と思ってたのですが互換性高くて移行しやすいし、動作も速くていい感じです。 概要 yarn = フロント(js)のパッケージマネージャ Facebook発、オープンソース、BSDライセンス npmと互換性がある npmと同じpackage.json, node_modules/で構成される コマンドも似ている バージョンの厳密な管理ができる package.jsonでバージョンそのものではなく、許容するバージョンの範囲を指定する 実際にインストールされた際のバージョンはyarn.lockに記録され、別マシンで再現可能になる npmに比べて高速に動作する 導入 Homebrewあるいはnpmでインストールできる。
最強のフロントエンドの雛形作った (2016/12/31) - Qiita
yarn とりあえず yarn install と yarn start だけで動く npm(yarn) scripts babel/webpack での多段ビルド build:js はChromeでだけで動くビルドを吐く（デバッグを容易にするため） build:js:production はIE11+ ava/nyc/istanbul でテストとカバレッジ postcssでCSSのビルド uglify-js/csswring で圧縮 CircleCI eslint, flow, ava release ブランチに push で gh-pages にデプロイ ## やってないこと React も Angular も jQuery も何も入ってない。あくまでそれ以前にやることをまとめた。 参考になるだろうけど、人によっては使わないツールも多いと思われるので、適当に削ってください。 こういうの
自分がnpmでグローバルにいれているcliツールまとめ - Qiita
今自分がなに使っているのかわからなくなってきたのでまとめました。 JavaScriptをよく書くので、それ周りのツールが多いと思います。 基本的に、nodemon, webpack, flow-binなどは各種プロダクトでnpm scriptとして登録するためglobalには入れません。 webpack-cliできたらグローバルにいれるかも npm, パッケージ周り https://github.com/sindresorhus/np npmへのpublishに使います。 npm versionでもいいのですが、こちらのほうがテスト、タグとバージョンコミットをpushまでしてくれるので自分はよく使います。 yarn https://github.com/yarnpkg/yarn パッケージマネージャーです。 最近のossプロダクトにはyarn.lockが入っていることが多く使う頻度は高めで
npm互換のJavaScriptパッケージマネージャーYarn入門 - ICS MEDIA
最近のWebのフロントエンド開発ではライブラリの管理を行うパッケージマネージャーの採用が主流になってきています。たとえば、タスクランナーのGulpやGruntであったり、SassやTypeScriptのコンパイルのためにNode.jsノード・ジェイエス（npm）を導入している方は多いでしょう。 JavaScriptのパッケージマネージャーとしては「npmネヌ・ピー・エヌ」が有名ですが、2016年10月にFacebookが新しいパッケージマネージャー「Yarnヤァン」を公開しました。 Yarnはnpmと互換性のあるJavaScriptのためのパッケージマネージャーで、「インストールが高速」「より厳密にバージョンを固定」「セキュリティが高い」といった魅力があります。弊社はnpmからYarnに乗り換えて早3年、快適に開発に利用しています。本記事では、npmの経験者に向けてYarnの利点と使い方を
Reactコンポーネントをnpmパッケージとして開発する - Hatena Developer Blog
こんにちは！ブログチームの id:amagitakayosi です。 今回は、業務で書いた小さなReactコンポーネントをnpmパッケージとして分離した話をします。 今回公開するパッケージ 実装方針 なぜnpmパッケージにするのか 他のコンポーネントの影響で壊れることを防げる アドホックな修正の積み重ねで複雑になることを防げる 本体プロジェクトのコードを削減できる デメリット Babelなパッケージのディレクトリ構成 実装 npmの注意点 reactはpeerDependenciesに入れる npm link を用いてローカル開発する場合、npmはpeerDependenciesを解決できない browserify-shimを利用する場合 npm publish 次回予告 追記 今回公開するパッケージ www.npmjs.com 今回は「無限スクロール」のためのReactコンポーネントを作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
会計freee が yarn から npm に出戻った本当の理由