今モノレポやるならどのツール使うのがいいのん?? - Qiita
はじめに こんにちは、「拳で」 と申します! NRI OpenStandia Advent Calendar 2023の16日目は 今モノレポやるならどのツール使うのがいいのん?? というタイトルでお送りいたします! 最近モノレポで開発することがあり、モノレポ管理を行うためのツールってちょいちょい聞くけど何が勢いあるんだろう?と気になったので調べてみました。 皆様のおすすめのツールや設定などがございましたらぜひコメントで教えていただけると大変喜びます🙇♂️ TL;DR フロントエンド(JavaScript/TypeScript)開発プロジェクト向けモノレポ管理ツールは、 npm Workspaces・Lerna・Nx・Turborepo が勢いがある 各ツールの選定基準は個人的に以下を推奨 ライトに手早くモノレポ管理したい： npm Workspaces 複数のnpmパッケージの開発・
Express+TypeScriptをはじめるときにやったこと - くらげになりたい。
Expressでサーバ立てたいなと思ったので、 TypeScriptではじめるときにやったことの備忘録。 TypeScriptの設定 まずは、package.jsonから。 # package.jsonの生成 $ npm init # typescriptのインストール $ npm i -D typescript @types/node # バージョン確認 $ npx tsc -v # ts初期化: tsconfig.json生成 $ npx tsc --init tsconfig.jsonの設定する。 // tsconfig.json { "compilerOptions": { "target": "ES2019", "module": "commonjs", "sourceMap": true, "outDir": "./dist", "strict": true, "esModul
フロントエンドでもTrivyを使って脆弱性対策したい！ - Qiita
伝えたいこと フロントエンドもコンテナ経由でアクセスさせよう コンテナならTrivyを使ってヤバそうな脆弱性を知ることができる TrivyならCIに組み込むことも簡単 multi-stage buildの場合は工夫が必要 いまの状況でできる範囲の脆弱性対策からはじめよう 今回の記事でできること CI上で、本番用のフロントエンドのコンテナをmulti-satge buildでつくり、 Trivyを利用して脆弱性を検知するところまでを目指します。 最後に、Trivyを利用したレベル別の運用イメージも提案します。 導入 週末、Trivyというコンテナ向けの脆弱性検知ツールが正式リリースされました。公開が5日目の5/21 12:00時点で 900star以上獲得しています。 Trivyの詳細は原作者である @knqyf263 さんの｢CIで使えるコンテナの脆弱性スキャナ｣という記事を参照ください。
脆弱性のあるJavaScriptライブラリの使用を防ぐには / #sec_kansai 14
総関西サイバーセキュリティＬＴ大会（第14回） ( https://sec-kansai.connpass.com/event/122914/ ) でJavaScriptライブラリの脆弱性に関する発表を行いました。
Parcel入門 - TypeScriptの導入方法 - ICS MEDIA
「TypeScript」とは、JavaScriptに「型」を指定できるオープンソースのプログラミング言語です。型によりプログラム実行前にエラーを見つけ出すことができるため、大規模なプロジェクトを安全に開発できます。Microsoft社製で、多くのフロントエンドエンジニアに採用されています。 TypeScriptのモダンなビルド環境を作るためにはwebpackやGulp.jsがよく使われていますが、設定ファイルが必要で学習コストは高めです。「TypeScriptのビルド環境がほしいだけなのに、なぜツールの設定に時間をとられるのか？」「TypeScriptを始めるときに苦労したくない」と思っている人も多いのではないでしょうか？ 「Parcelパーセル」というツールを使うと、独自の設定ファイルを使うことなくTypeScriptのモダンなビルド環境がわずか3ステップで作れます。 ▼ TypeScr
サーバーサイド経験者に贈るフロントエンド技術の学び方 - Qiita
この記事は クラウドワークス Advent Calendar 2018 の4日目の記事です。 はじめに クラウドワークスのフロントエンドチームでエンジニアをしています @eighty8 です。 2018年9月に入社しました。 長らくソシャゲのサーバーサイドエンジニアをやってまして、本格的にフロントエンド開発に携わるのはクラウドワークスに来てからになります。 フロントエンドエンジニア1年生になってみて最初に感じたことは、 「周辺技術が多過ぎてどっから手をつけていいのかわからんちん。。。」 です。 Frontend Roadmap というのを見みてもわかる通り、フロントエンドもこのボリューム ∑(ﾟωﾟﾉ)ノ 今まで断片的に情報は掻い摘んできてたんですが、それじゃダメだ・・・と痛感しました。 まあ、これらすべてに精通している必要はないと思いますが、HTML書けます、CSS書けます、ついでにJa
すべてのpackage.json に含まれた方が良いと思うもの - Qiita
{ "devDependencies": { "eslint": "github:eslint/eslint", "husky": "github:typicode/husky", "tslint": "github:palantir/tslint", "lint-staged": "github:okonet/lint-staged", "npm-run-all": "github:mysticatea/npm-run-all", "prettier": "github:prettier/prettier" } } Formatter is 正義 JavaScript 業界がここ数年でSyntaxが豊かになるだけでなく、何より開発環境が劇的に進化したと感じています。 代表的なものとしては TypeScript や FlowType のような型情報を付与する概念ですが、 合わせてストレスフ
package.jsonで値を展開する - 技術探し
🎍今年初の記事です🎍 そういえばこんな機能あったなーって感じだったので記事にしてみました。 本当は今年最初の記事用意していたのですが、まだ終わってないので後ほど。。 github.com 今回は、タスクのstartとbuildに同じ変数をwebpackへ渡すために共通化したくて、量が多くなってきたのでリファクタリングしました。 手順 文字列の場合 オブジェクトの場合 配列の場合 まとめ 手順 $npm_package_にpackage.jsonに書いたkeyをつなげるとそれのvalue展開されます。 コンソール上では、展開されませんが、JS上では展開されます。 // 確認用のJS console.log(process.argv[2]); $ npm run main > node main.js $npm_package_foo bar 文字列の場合 { "foo": "bar",
全部知ってる？ npmを使いこなすために絶対知っておきたい10のこと
知っておくと便利なnpm（Node Packaged Modules）のコマンドとTipsを全部で10本まとめました。 Facebookの新しいYarn projectには興奮を覚える一方で、Node.jsの躍進にはオリジナルパッケージであるnpmの存在が大きく貢献しています。 少ないnpmのコマンドで、初期化したり（npm init）、パッケージをダウンロードしたり（npm install）、テスト（npm test）したり、プロジェクト内でカスタムスクリプト（npm run）を作ったりできます。少し詳しく調べていけば、日々の開発を劇的に変えてくれるさまざまなコマンドがnpmには用意されています。 注意：もしnpmの手引きが必要なら『A Beginner’s Guide to npm — the Node Package Manager』をチェックしてください。npmとYarnの違いにつ
Node.jsユーザーなら押さえておきたいnpm-scriptsのタスク実行方法まとめ - ICS MEDIA
ウェブ制作の現場では作業の自動化を行うことが多いです。Node.jsインストール時に付属するnpm (Node Package Manager)を使用すれば、タスク処理が実現できます。 npmとはNode.jsのモジュールを管理するためのツールであり、タスク処理にはnpmの機能のnpm-scriptsを使用します。本記事はnpm-scriptsを使ったタスク実行環境が構築できることを目標に解説します。 そもそもnpm-scriptsとは何か？ npm-scriptsとは、package.jsonファイルに記述可能なシェルスクリプトのエイリアスです。エイリアスとはコマンド名を別のコマンド名に置き換えることです。以下のnpm-scriptsはHello world!!を表示させるコマンドのエイリアスを作成する例です。 ▼package.jsonファイル { "scripts": { "say"
sprockets + rails-assetsを卒業して、npm + webpackへ移行 - ただのにっき(2016-05-19)
■ sprockets + rails-assetsを卒業して、npm + webpackへ移行 1年少々前、Webアプリのフロントエンド開発環境として暫定的にRails Assetsを使うことにしたのだけど、あれからjs界隈もしだいに落ち着いてきて*1、いろいろと勝ち組っぽいツールが決まってきた気がする。 そんなわけで、徐々にそっち方向へ移行してこうかな、と。とくにRails Assetsはサービス自体が終了の方向らしいので、まずはそのへんから。jsのパッケージマネージャとタスクランナーの勝ち組として、おれの観測範囲でみえてる感じだと: パッケージはpackage.jsonをnpmで管理するのが一番シンプル タスクランナーもnpmでいいよもう……という流れが強そう AltJSは使わずにES2015、ビルドにはWebpackとBabelの組み合わせ ってところか? 少し前に話題になった「1
npm-scripts で使える便利モジュールたち - Qiita
npm はパッケージ依存管理ツールであると同時に、便利なタスク・ランナーです。 本体はごく基礎的な機能だけを持ち、npm が管理するパッケージと Shell の力を組み合わせてタスクを定義します。「npm-scripts で利用する CLI コマンドは npm で管理できる」という分かりやすさが気に入っています。 npm-scripts には以下の特徴があります。 多くのツールが CLI を持っているためにラッパープラグインが不要です。Gulp ラッパー プラグインは非公式であることも多く、メンテナンスが継続するか不安な場合があります。 簡潔です。Gulp で書くと数十行だった処理が数行になるなんてこともよくあります。 複雑なことをするには向いていないです。 環境変数の扱いに難があります。 この記事では、私が npm-scripts を書くときによく利用している便利ツールたちを紹介します。
Lerna を使って、 Babel や React が採用している monorepo を試してみる - Qiita
monorepo とは 複数の npm package を 単一の git repository で管理すること 例えば Babel では、 100 以上の npm package が単一の git repository で管理されている https://github.com/babel/babel/tree/master/packages package 毎に repository を作る場合と比較した Pros & Cons Babel の repository のドキュメントから抜粋 Pros: lint, build, test, release のプロセスを共通化できる package をまたがった修正が容易になる issue 管理を一元化できる 開発環境の構築が簡単になる テストも package をまたいで実行でき、複数 package が絡む不具合の検知が容易になる Con
Railsのフロントエンドのビルドをnpmコマンドのみで完結したい - Qiita
こんにちは、freeeでエンジニアをやってます @yo_waka です。 これは、freee Engineers Advent Calendar 2015の11日目の記事です。 これまでの弊社のAdvent Calendarでは、社内で革命と呼ばれるフロントエンドの改善ネタが多いと思いますが、その流れとして、RailsアプリケーションにおけるフロントエンドのビルドツールであるところのSprocketsをどのようにしたら外せるかという話を書きます。 Sprocketsがやってくれること まずはSprocketsが裏側でどういうことをやっているのか知る必要があります。 Advent Calendar4日目の記事で既に概要が書かれていますが、もう少し細かく内部動作に踏み込んで書いてみます。 尚、Sprocketsのコードは現状のRailsの最新版である4.2.5で利用されている、Sprocket
npm initでauthorやlicenseなどの初期値を指定する - teppeis blog
JavaScript Advent Calendar 2015の2日目。小ネタです。 npm initするときにauthorとかlicenseとか毎回同じこと入力するの面倒だったりしません？実はいくつかの項目は初期値を設定できるのだけど、ググってもあまり日本語情報が無いようなので共有。 設定方法は.npmrcで以下のように指定すればOK。 init-author-name=Teppei Sato init-author-email=teppeis@gmail.com .npmrcの場所は以下の順で優先される。（詳細は公式を参照） per-project config file (/path/to/my/project/.npmrc) per-user config file (~/.npmrc) global config file ($PREFIX/etc/npmrc) npm buil
npm v2のインストールは`npm i -g npm@latest-2` - teppeis blog
タイトルで言い切った感のある小ネタ。 最新のnpm v3は基本素晴らしいのだけど、主にnode_modulesがフラットになったなどのbreaking changesによって一部のパッケージがまだ非対応だったり、自分のプロジェクトで固めたshrinkwrap.jsonからは対応前の古いパッケージを参照していたりすることが稀によくある。 そういうケースではnpm v2系を使い続けたいのだけど、インストール時に $ npm i -g npm@2 でインストールするとv2系の正式リリース版ではなく、プレリリース版が入ってしまう。 npmプロジェクトではリリースをdist-tagsで管理していて、まずRC版をnextタグとしてプレリリースをして、問題なければ次のリリースでlatestとして正式リリースするプロセスになっている。 v3系がリリースされたので上記のタグはv3系が使ってしまっているが、v
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Yarn + CI + GitHub で挑む npm パッケージの定期更新
https://qiita.com/watilde/items/340b57ef289142b27899
GitHub - sindresorhus/awesome-npm: Awesome npm resources and tips
【npm + Karma + Jasmine】JavaScriptの単体テスト環境を構築する - Qiita
