[めも]pixi.js関連

#元ねた
webpackちゃんと理解しとこ browserifyなライブラリ(pixi.js)をrequireしようとした編

##元ねたをざっくりまとめると、
・browserifyされたライブラリをwebpackしようと思ったら、うまくいかなかった
・原因は、brfs(browserify用のfs)などの、トランスフォーマ
・その問題を回避するために、webpack用のローダを使う

#現状
※関連記事を拾う所で(寄り道しすぎて)力尽きたので、未検証です。
訳は、かなり端折ってます。

##現状のざっくりまとめ。
・webpack用のローダは不要になった(PIXI.js v4.1.1以降)
・brfsは使わなくなった(PIXI.js v4+)

Gist - Using webpack with pixi.js

darkowic commented on 16 Nov 2016
In new PIXI v4.1.1 transforming is not needed anymore! They fixed 'main' in package json in mr pixijs/pixi.js#2981.
Now importing from pixi works well with webpack!

import {Point} from 'pixi.js';

訳:PIXI.jsは、v4.1.1以降、トランスフォームが必要なくなりました。
(import関連の不具合対策などで)mainも直したので、webpack用にimportしても問題なく使えます！

##ここからしばらく、旧情報
(同Gist)

coryasato commented on 5 Aug 2016 • edited
Works for v3+. For v4+ I had to use ify-loader, glslify complains about a transform.
・・・
Thats it, I removed transform-loader and brfs from my deps and it rolls fine.

訳:PIXI.js v3+なら、(brfs用のtransformローダを指定する方法で)上手く行きます。
v4+の場合は、glslifyが問題になるので、ify-loaderを使います。
※この部分は、v4.1.1より前の情報なので注意

さらに少し前の関連Issue
Compatibility with webpack #1854

englercj commented on 29 May 2015
We use browserify brfs transform

(細かい経緯は省略)

Nazariglez commented on 12 Nov 2015
Webpack has an option to load "pre-packed" libraries without parse it (like pixi.js), just add noParse to your module section at webpack config, something like that:

module: { noParse: [ /.*(pixi\.js).*/ ], }

This snippet must solve the problem with the internal requires.

訳:たらい回しオプションもあるよ
(この後、上のGistに続く)

##補足
・どうしてもうまく行かない場合は、pixi.jsのlibディレクトリなどにあるファイルを使えば行けるはず
詳細は、pixi.jsのHow to buildを参照。

(pixi.jsのpackage.jsonの、scriptsのdistを実行すると、distディレクトリにあるpixi.jsなどができる≒libディレクトリなどにあるものが、pixi.jsのソース。それをpixifyで、Browserifyしている。)

---

#BrowserifyとWebpack　(少し長め)
(Browserifyなどで)すでにパッキングされているライブラリを、別のツール(Webpack)で再パッケージングするのはどうなの？
という議論があったのを見つけたので。
※2014年の7月なので、かなーり前です。(当時のwebpackは、まだv1です。)
蛇足:せっかくなので、webpackのリリース履歴から、v2がいつ頃出始めたかを探してみると・・

on 2 Nov 2015 v2.0.0-beta

##ざっくりまとめ
TL;DR (長すぎ！) って、こういう時のためにあるよね！
というのは置いておいて、

・Browserifyなどで(ブラウザで利用する事が前提の)パッケージとしてまとめられたライブラリは、再度、他のパッケージに詰め込まれる事は考慮していない

これが全てかと思います。
それでも、やっぱり再パッケージしたい・・というわけで、色々な意見が出た模様です。その結果、ライブラリでは、パッケージにまとめた元のファイルも同梱してはどうか方向に話が進んだようで。

元記事から。(webpackのIssue)
Loaders & Dependency Management #378

Browserify されたパッケージをwebpackで再パッケージしようとしたらエラーが出た、という質問から始まって・・
(最初の部分は省略。経緯を知りたい方は、このあたりを参照で。)

dashed commented on 27 Jul 2014 (Contributor)
Just saw your post via hacker news: http://mattdesl.svbtle.com/browserify-vs-webpack
・・・

忘れてはいけないポイント。

dashed commented on 28 Jul 2014 (Contributor)

@mattdesl In practice, published modules in npm aren't supposed to be compiled in webpack/browserify; or even rely on the end-user to compile it via webpack/browserify. Ideally, if it can play well within both the browser and node.js (or similar), they should be environment agnostic, and as well as bundler agnostic as possible.

If a module author does use webpack, it's usually to publish a browser version which are usually published to appropriate channels such as bower.
・・・

訳:実際の所、npmにアップされたモジュールは、webpackやbrowserifyで使う事を意図したものではありませんし、エンドユーザがそれらでコンパイルする事に依存するものでもありません。
仮に、そのモジュールがブラウザでもNode.js(または類似したもの)で上手く動作したとしても、環境に非依存であるべきですし、可能な限り、バンドラにも非依存であるべきです。

モジュールの作者がwebpackを使ったなら、通常はブラウザ用バージョンとして公開されるでしょうし、bowerのような場所に公開されるかと思います。

訳注:(ライブラリの)コードを再利用する時に、依存関係などを調べて、手動で設定ファイルを作るのは良い方法ではない、などのコメントに対するレスです。

sokra commented on 30 Jul 2014 (Member)

I also think that publishing a build version is not a good solution for npm (in bower this is more common).

訳:(bowerでは一般的かもしれませんが) npmでbuild版を公開するのは、あまり良くないかと思います。

この後、公開するにしても、依存関係回りで複雑な問題が発生しそうなので、良い方法はないか、(webpackだけのスペックになってしまいますが)・・という方向に話が進みます。

そして、やっぱり話題にのぼる、このメンバー。

mattdesl commented on 5 Aug 2014
In many cases a transform is not a simple "import" statement. Examples:

brfs
glslify
envify
es6ify
sweetify

etc..

見事にかわし・・

petehunt commented on 5 Aug 2014
I'm with you on avoiding overloading require(). Relative to this spec, I think require() should have the exact same semantics as node does (this is contrary to what webpack does). My spec instead uses a requireStatic() global function to introduce these new semantics.

訳:(brfsで読むような)静的なデータなら、requireStatic()でいいんじゃない?

きれなかった。シェーダ、どうしよう?

mattdesl commented on 6 Aug 2014
The ! require syntax would not really work with glslify:

var myShader = glslify({
     vertex: ' ... inline GLSL shader code ... ',
     fragment: ' ... inline GLSL shader code ... ',
     inline: true,
     sourceOnly: true
})

という感じで話が進んで行き・・

jhnns commented on 5 Nov 2014
Btw: There is a related blog post on npmjs.org http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

この日付あたりに、色々楽しいできごとがあったようで・・

jhnns commented on 22 Apr 2016 (Member)
Haha, you've summoned a monster by reviving this thread

ついには、モンスターまで召喚した模様。
やっぱり、requireとかinclude周りは、どの言語でも苦労する所らしいです。

話がそれましたが、気になった方は、元記事で。

#あとで読むためのメモ
Stackoverflow - Managing jQuery plugin dependency in webpack