タグ

ブックマーク / qiita.com/azu (6)

  • lernaでincludeMergedTagsを設定しないとマージコミットが変更として検知されてしまう - Qiita

    lernaではlerna version --conventional-commitsというように--conventional-commitsオプションを使うことで、コミットから次のバージョンを推測できます。 詳しくはlernaでのmonorepoにおけるリリースフロー(Fixed/Independent) | Web Scratchを参照。 しかし、この--conventional-commitsはデフォルトでは問題があります。 GitHubではPRをマージするとマージコミットが作られますが、このマージコミットも変更のコミットとして扱われてしまいます。 タグ付け後のマージコミットが全体の変更として扱われる これによって、変更してないけどマージコミットによって、バージョンを上げないといけないといった判定になってしまいます。 この問題を回避するため、lernaには--include-merg

    lernaでincludeMergedTagsを設定しないとマージコミットが変更として検知されてしまう - Qiita
  • JavaScriptフレームワーク選定の議論 - Qiita

    相談内容 既存の管理ツールを新しく作り直すために新しいJSフレームワーク/言語使いたいのですが、何を選んだらよいでしょうか? ここで選んだものは今後新しく作る時にも使用していく予定のため、学習コストよりメンテナンスしやすいものを選びたいと考えています。 利用者は社内外で特定の権限を持った人のみであるため、サーバサイドレンダリングはしない予定です。 言語は型があるものを利用したいのですが、TypeScriptとFlowのどちらがよろしいでしょうか? 時間に余裕があれば、テストフレームワークやビルドツールについてもお聞きしたいです。 現在のページ/チーム jQueryなどで書かれている部分が多いですが、変更を加えることが難しくメンテナンスコストが高いです。 サーバサイドをやってる人が片手間で書くJavaScriptといった状況です。 今回新規で数ページを追加する必要があるため、何を利用すれば良

    JavaScriptフレームワーク選定の議論 - Qiita
  • Lerna(monorepo)とCHANGELOG(リリースノート) - Qiita

    Lernaなどのmonorepoツールを使っていて困るのが、Conventional Changelogなど既存のリリースフローがそのまま適応できない点です。 さらに、Lernaの中でも管理モードが2つありそれぞれでCHANGELOGの管理に使えるものが異なります。 Lernaでパッケージを管理する際大きく分けてFixedモードとIndependentモードがあります。 Fixedモード 管理下にあるパッケージがすべて同じバージョンとなるモード 採用例): Babel、Jest このモードに対して使えるツールとしてlerna-changelogがあります。 BabelやJestなどが利用しています。 GitHub PRにつけたラベルを元にジャンルを分けてCHANGELOGを吐き出すツールです。 Independentモード 管理下にあるパッケージがそれぞれ異なるバージョンとなるモード 採用

    Lerna(monorepo)とCHANGELOG(リリースノート) - Qiita
  • Reactのサーバサイドレンダリングとパフォーマンスについてのメモ - Qiita

    Reactのサーバサイドレンダリングとパフォーマンスについて調べてたのでメモ 基的なこと サーバサイドとReactのproduction build 要約: Reactをサーバサイドで使うときも、クライアントサイドのように圧縮(というよりはcode eliminate)しないと遅い Reactはdev向けのコードを大量に含んでいる。 これはprocess.env.NODE_ENV !== 'production'の時実行されるassertや警告などが主となりproductionには必要ない。 そのため、process.env.NODE_ENV = 'production'をしないとかなり不利な結果を得る。 I tend to agree that "compiling server side code with webpack to remove access to process" i

    Reactのサーバサイドレンダリングとパフォーマンスについてのメモ - Qiita
  • JavaScriptライブラリ/プロジェクトのファイルサイズの問題点を見つける方法 - Qiita

    ブラウザ向けのJavaScriptだとファイルサイズはある程度気になると思います。 この記事では、ファイルサイズの計測方法やボトルネックとなってるライブラリの見つけ方についてできるだけ簡単な方法をまとめます。 ファイルサイズと一言にいっても、ブラウザでは大体minifyしてから配布するのでminify後のファイルサイズも重要です。 ソースコード自体のファイルサイズ minifyしたファイルサイズ minify + gzipしたファイルサイズ コメントの多いソースコードはminifyするとかなり小さくなったりすることが多いので、ソースコード自体のファイルサイズでは比較しにくいです。 また、ソースコードにおいて assert モジュールを使っているとファイルサイズが10kb弱程度minify後で変わります。 assertモジュールは通常外しても問題ないので、unassertでビルド時に取り除き

    JavaScriptライブラリ/プロジェクトのファイルサイズの問題点を見つける方法 - Qiita
  • ECMAScript modulesとCommonJS modulesの使い分け - Qiita

    個人の感想です。 規約 相対パスは ECMAScript modules で import/export それ以外は Common JS で require/module.exports 意味 内界 - プロジェクト内のコードはECMAScript modulesでやり取り 外界 - npmパッケージを require や、package.jsonの "main" へのexportはCommonJSでやり取り 例 const fs = require("fs"); const path = require("path"); const mkdirp = require("mkdirp"); const Promise = require("bluebird"); const debug = require("debug")("textlint:cli"); import options f

    ECMAScript modulesとCommonJS modulesの使い分け - Qiita
  • 1