Q&A
回答者はエスパーではないので、package,json の内容 (せめて node-sass と衝突するライブラリの情報) がないと答えようがないのでは…。
エキスパートのみなさん、こんにちは
gyp ERR! が発生しました。
原因はnode-sassがnode.jsと合わないためです。
そこで解決方法をご教授いただければ幸いです。
詳しい状況===
現実行環境は以下の通りで問題ないのですが、
（node.js v16.3.0, node-sass 6.0.1）
利用したいライブラリがnode-sass ^4.14.1に依存しており、そこでエラーが発生しています。
この場合の対処方法は次の2つしかありませんでしょうか。
- 現実行環境をnode-sass ^4.14.1に対応するnode.jsにダウングレードする
- node-sass ^4.14.1に対応するnode.jsを用意した、実行環境をdockerで構築する
なるべく実行環境は変更せずにしたいので、例えば利用したいライブラリの依存関係を変更して利用できる方法などございましたら、ご教授くださいませ。
宜しくお願い致します。
この投稿に明記しているつもりですが、
node.js v16.3.0とnode-sass ^4.14.1が衝突しているかと
この場合衝突という表現があっているかわかりませんが。
兎にも角にも、わかりにくい表現でしたら申し訳ありません。
失礼しました。衝突じゃなくて node-sass ^4.14.1 に依存しているライブラリを聞くつもりでしたが、すでに回答がついたようなので忘れてください。
左様でしたか、ご協力いただきありがとうございます。
回答1件
0
ベストアンサー
一応注意喚起です。
node-sass(LibSass)はDeprecated(非推奨)なので
sass(DartSass)に移行しましょう。
参考記事:
上記を踏まえて質問文の問題にどう立ち向かっていくのかを考えていきましょう。
利用したいライブラリがnode-sass ^4.14.1に依存しており、そこでエラーが発生しています。
こういう依存ライブラリがメンテされずにプロジェクトが死ぬみたいなケースはしょっちゅう発生します。
まず検討するのは下記です。
- 何故そのライブラリを使わなければならないのか？目的は？
- 代替ライブラリはないのか？
- 使い続ける覚悟をした場合の方法とは？
質問文は最初から3番を検討してます。
node-sassはnode-gyp(C++の拡張モジュール)を利用しており、インストールするだけで一大事です。
そしてそいつが本流ならともかく、非推奨のLibSassということで開発者達は泥舟から次々と逃げています。
なんでそのライブラリはLibSassにしがみついているのか？
単純にわかってないだけとか、メンテせずに放置してるだけとか色々考えられます。
そんなの使う価値あるんですか？
まずそこを考えて見てください。
- 現実行環境をnode-sass ^4.14.1に対応するnode.jsにダウングレードする
- node-sass ^4.14.1に対応するnode.jsを用意した、実行環境をdockerで構築する
どちらもあまりパッと来ないですね。
別プロジェクトに飛ばしてしまって
SassからCSSを生成して、本流のプロジェクトでCSSファイルを使わせて頂くみたいな解決策はあります。
Node.jsのバージョン管理ツールでVoltaとかどうですかね。
機能の一部にpackage.jsonに依存するNode.jsやnpmのバージョンを保管して
それを呼び出すみたいな芸当もやってのけるので、用途には合ってます。
参考記事: Node.jsのバージョン管理にVoltaを推したい - Zenn
このCSSファイルを生成するプロセスはnpm-scriptでやるのも良いですが、
Dockerに包んでも良いと思います。
Volta前提というのもまたちょっと微妙なので、Dockerの方が良い案に思えますね。
例えば利用したいライブラリの依存関係を変更して利用できる方法などございましたら、ご教授くださいませ。
一番検討したいのはプロジェクトのForkですね。
npmはGitHubのURLを指定すれば、そこから取ってくるみたいな芸当も出来ます。
参考記事: Githubまたはローカルのnpm のパッケージをinstallする方法 - Qiita
元のモジュールがnpmで配布されているなら
多分GitHubで公開してるんじゃないですか？
それを自分のアカウントでForkしてプロジェクトを丸ごとコピーします。
後は丸ごとコピーしたプロジェクトのpackage.jsonをnode-sassからsassに変更。
プログラムの至る所でエラーで落ちると思うので、
エディタでnode-sassを使っている箇所を検索して洗い出して
sassパッケージ流儀の書き方に修正。
これで一通りファイルを吐き出して特に問題が無ければ
お目当てのライブラリで導入する時に自分のGitHubのリポジトリを指しながらインストールするだけです。
GulpやGruntはもう下火ですので、
昨日の常識は明日の非常識。
同じライブラリを使い続けるならば、マイナーな言語やライブラリを使い続けるならば
こういうアプローチは必要になるでしょう。
投稿2021/08/24 12:43
総合スコア21158
ご回答ありがとうございます。
とてもご丁寧に、なおかつ私の存じ上げない解法をご紹介いただいたことに重ねて感謝申し上げます。
Forkが最も有効ということで、採択させて頂きます。
ちなみにForkは勝手に行なっていいものなのでしょうか。
権利関係に疎く、ご教授いただけますと幸いでございます。
それと miyabi-sun 様のこういった知識は、
teratailのようなサイトを追っていくと身につくものでしょうか。
> ちなみにForkは勝手に行なっていいものなのでしょうか。
GitHubは建前上の話をすればプロジェクトルートにLicenseファイルを置くルールがあり、
それに書かれている事が許諾になります。
ファイルが無ければ弄ったり複製しちゃダメ。
ですがそもそもGitHub上で「パプリックリポジトリ」として全世界に公開している時点で
基本的には複製・改造されるのは覚悟の上です。
複製されたくなきゃ「プライベートリポジトリ」に設定しなよ……
また赤の他人のリポジトリは「勝手にコミットしてPush」みたいな事は出来ません。
そんなことしたら悪い奴がオープンソースのプロジェクトにコンピュータ・ウィルスを仕込み放題になりますからね。
その代わりに用意されているフローがあります。
プロジェクトを自分アカウントにフォーク(複製)して、修正を加えたブランチを作成。
オリジナルの開発者に「自分の修正を加えたブランチ」を使ってプルリクエストという形で提案する事が可能です。
私が提案している内容はそのプルリクエストを送る直前の段階ですね。
人に英文書いて提案するって大変ですから、勝手に直して使わせて貰ってるよみたいな体です。
> teratailのようなサイトを追っていくと身につくものでしょうか。
受け身じゃダメです。
Twitter・Qiita・Zenn等で色んな人の記事を読みまくりましょう。
teratailは回答者側として活動しないとあまり成長しないかと思います。
回答を書くのに調べますし、ぱぱっと調べる能力が身につきますし、取捨選択の能力や、文章に纏める能力が身につきます。
諸々とても勉強になります。
本当にありがとうございます！!
あなたの回答
tips
プレビュー
