【node.js】サーバサイドjavascript 5【Nashorn】
>>660 いや実際660はそうしてるだろ。俺も以前嵌った事があったし、 実際セミコロン必須の言語だとどこで切ってもいいから、660の書き方はよく見るよ。 俺はお前がおかしいと思うが。 結局これもMDNで説明するのに例外扱い("no LineTerminator here" 規則)になってるし。 統一された文法ではないよね。(=もっとましな仕様にする事も出来たし、実際他言語はそう) >>666 その書き方よくみるというけど 1行で書けば見やすいのにわざわざ複数行で見にくくしている意図がわからない >>668 そりゃ、そうした方が見やすいと思う人がそうするだけだよ。 お前がそう思わなければしなければいいだけ。 ただ実際、660にある公式のコードもそうなってるだろ。 俺も個人的には横に長いコードを書くけど、一般的には縦に長いコードの方が多いと思うよ。 returnの直後に改行してないからASI関係なくないか? >>670 660の「新しい記述方法だと動かない」とされてるコードは return gulp で改行してる。 660内の公式はこれが出来ない事を知ってるから、 gulp.src(...) で改行してる。(ただしreturnはないが) >>669 それは長い行を分けて改行しているだけ 一方で>>660 の人は長い行にならないのに無意味に改行しまくり >>671 return gulp.src() ならreturnの後にセミコロンが自動挿入されるけど return gulp .src() ならgulpの後にセミコロンは自動挿入されないでしょ それよりfunction ejs(){}って名前がダメなんじゃないの? .pipe(ejs())で再帰になってる >>672 長さではなく、意味で切るんだよ。 >>673 > return gulp > .src() > ならgulpの後にセミコロンは自動挿入されないでしょ されて gulp が返されるはずだぞ。 >>674 意味で切るならgulpと.src()の間で改行を入れてるのは明らかにおかしい 無意味な改行だ >>673 すまん、674は間違い。 試してみたところ、確かに挿入されないようだ。 >>675 相手するだけ無駄っぽいが、そういうのは物によるんだよ。 そうした方が見やすいと思う奴がそうするだけ。 return ウンコ製造器675号 .src(ケーキ) .pipe(胃) .pipe(小腸); .pipe(大腸); なら、675によってケーキがウンコに変わるのが見やすくなると思う奴もいるだろ。 (詳しくないが)gulpの場合は基本はフィルタで型が変わらないし、出発点はソースファイルに決まってるから、 return gulp.src(ソース) .pipe(フィルタ1) .pipe(フィルタ2) のケースが多いとは思うけど。 ついでに言っておくと、お前JSによくいる、やたら文法に拘る奴なら、止めた方がいい。 それだと全く進歩しないので。 上記の通り、まあどちらもいるわな、程度で進めていかないと、上達しない。 どちらが正しいとか、そういう問題ではない。 どうにもJS初心者は「改行を極める」「セミコロンを極める」とかになりがちのようで、よろしくない。 んじゃ俺は括弧の後に半角スペースを入れるのを極めるわ。 .NET Standard が世界の中心と考えてる人でしょ 別スレで見た 610です。 仕事でレス遅くなりました。 >>673 ありがとうございます! このコメントからピンときて修正したら無事に動作しました。 超初歩的なミスでした、、 こちらの書き方は関数の中にejs(gulp-ejsオブジェクト)を書いても動作しましたが gulp.task('ejs', function() { } こちらでは関数に同じ関数入れたらまだタスク終わってないよと、動作しませんよね。(気づけば当たり前なのですが、、) function ejs() { } お騒がせしました。コメント頂いた方もありがとうございました! 漏れは、Ruby でも、パーサーの誤解釈を避けるため、 . を行末に置く a. b( ). c( ) >>687 JavaScriptで駄目なのはreturnのみの行の時だけだよ return a .b() は駄目だけどこう書く人はいないから問題は起きることはない return a .b() なら大丈夫 そういうのはコーディング時にいちいち気にするよりlinterでチェックだな。 >>688 それを知ってないと嵌るだけの無駄仕様だよ。 セミコロンなしの筆頭だったAirbnbも諦めたようだし。 > ASI contains a few eccentric behaviors, though, and your code will break if JavaScript misinterprets your line break. These rules will become more complicated as new features become a part of JavaScript. Explicitly terminating your statements and configuring your linter to catch missing semicolons will help prevent you from encountering issues. > https://github.com/airbnb/javascript#semicolons 他にセミコロンなしの有名ルール勢ってあったっけ? return 'qwerty' +'asdfgh'; とは書きたくなるだろ。書きたいように書けないのはよろしくないよ。今風ではないね。 セミコロン書くルールならASIなんて無い方がマシだし。 書き方にこだわりがあるならそうではない書き方と比べて◯◯の利点があると言わないと他人の理解は得られにくい。 好みだけの問題ならスクリプトの仕様に従うしかない。 >>681 俺向けではないと思うが、 return 'qwerty' +'asdfgh'; の利点は見れば分かるとおり、インデントを揃えられる事だよ。 タグの方が分かりやすいかもしれんが一々引っかかると面倒なので止めただけ。 return '<div>' +'<span>'+ +'</span>'+ +'</div>'; だと最初のdivのインデントがずれるだろ。 まあ言うほどではないし、実際俺はこの書き方をしているが、出来れば return の後に改行したいね。 お前ら何も考えずにPrettier使え それが今のデファクトだ >>696 ならAirbnbというのは俺の勘違いだな。 俺がJSを始めた2013-14頃、有名なコーディングルールが4つほどあって、Airbnbが一番トンデモだった(が、人気は一番という話だった) その中にはセミコロンを打つな、というルールもあった。誰か思えてないかね? なお俺はgoogleのルールが一番マシっぽいのでそれを参考にした。(こちらはセミコロンあり) >>697 どこだか覚えてないけど、確かにどっかでセミコロン打たないで、短文を1行に書くときだけセミコロン使うてなの見たか聞いたりした記憶ある。 一応自分でも再確認しているところだが、 > Always use semicolons. (google) > Use them. Never rely on ASI. (jQuery) > あなたからセミコロンを奪おうとする反抗的な軍隊があるようです。でも確かに私達の伝統的な文化はまだ元気に生き残っています。だからコミュニティに従って、セミコロンを使いなさい!(Node) > https://qiita.com/takeharu/items/dee0972e5f39bfd4d7c8 npmのもかなりトンデモだった記憶があり、改めて確認すると、打つな派だ。 > ;(x || y).performAction() > ;[a, b, c].forEach(performAction) > for (var i = 0; i < 10; i ++) { > switch (state) { > case 'begin': start(); continue > case 'end': finish(); break > default: throw new Error('unknown state') > } > end() > } > https://www.w3resource.com/npm/npm-coding-style.php となると俺の勘違いはnpmという事になるが、npm==Nodeじゃねえのか?という疑問は発生する。Nodeはnpmからのフォークか? 多分俺が当時見たのは Airbnb, npm, jQuery, googleだと思う。 NodeはRyan Dahlが始めてセミコロンあり npmはIsaac Z. Schlueterが始めてセミコロンなし IsaacはNodeの2代目リーダーだけどNodeではセミコロンを書いてた セミコロンレスの強硬派として有名なのはStandard カスタマイズも許さない https://github.com/standard/standard >>701 初コミット2015年なのにstandardと主張して他と違うルールとか、頭おかしいな。 とはいえ議論する時間が一番無駄というのは同意だが。 多分セミコロン無し言語出身者用のルールが一つは必要で、 それに向けてのstandard命名なのだろうけど、なんだかね。 文字列を「+」で繋げるのもうやめようよ。見にくいよ。 「´」(バッククォート)で括ればいいじゃん javascriptならセミコロン無い方がいいかなぁ async/awaitってawaitしかしないから無駄じゃね? Promise, async/await で無駄なのは、デタラメ解説の数々、ほぼ全滅だろ、酷い惨状だねー。 それを言ったらWeb系言語は全部デタラメ解説で駄目だろ 初心者が情報公開の練習として解説を書くからそうなる それはしゃーない、正確さにこだわりすぎて萎縮する方がデメリットが大きい 読む方が気を付けて取捨選択するしかない c++とかjavaとか含めて進化してる技術の古い解説はことごとくゴミ化してるし一緒だわな classは非推奨にして欲しい。 中途半端で使いにくい。 >>709 同意だが、C#はかなりマシ 一般的に上級者は初心者向けの説明なんて書きたくないものだが、 プログラミング自体について語りたい連中も多少はおり、そいつらを上手く取り込んでる >>712 上っ面だけのクラスベース。 内容はプロトタイプのまま。 上っ面といってもそこで整合とれていて内部の問題が表に現れないなら別に問題ないと思うが。 まぁ、中途半端というなら何かそういう部分が見えているということなんだろうが。 >>714 オブジェクト指向的センスが無いと言う事だね 今の時代、両方出来ないとプロだと厳しいと思うがね プロトタイプの方が表現出来る空間が広くて、実際にただの糖衣構文でクラスを実装出来てるだけだろ クラスで閉じて使ってる限りプロトタイプの側面は見えないはずだが 混ぜて使うのってありだっけ?(class宣言した物にgetPrototypeOfとか) class構文の時にどうプロトタイプが配置されるか仕様で確定してないと駄目だと思うが、これってしてるのか? GoやRustなんかの新しい言語がクラスベースのオブジェクト指向を採用しないご時世 時代遅れとなったC++やJava風のクラス構文を導入する必要はなかったわな TC39的にはES4で入れ損なったから悲願だったんだろうけど プロトタイプベースのオブジェクト指向ってIDEや静的型付けと相性悪いのでは >>720 仮にそうだとしても、IDEの都合を優先してプログラミング言語を簡素化するのは完全に本末転倒だろ 初心者専用のオモチャが欲しければScratchで満足しとけ >>721 既存との互換を保ったまま機能追加されてるわけだから言語自体は簡素化されたのてはなく複雑化されたのでは それはさておき従来の機能が使えなくなるわけでもなく何が不満なのかわからない >>718 してない。 だから細かい設定が解りづらい。 >>722 糖衣構文を導入した分言語は複雑化してるし、IDEも余計に対応する必要がある。 IDEを優先するなら何もしないのが最善。 (もちろん仕様を削れるのが最善だが、JSの場合はこれはかなり無理なので) >>723 仕様で確定してないのなら、混ぜて使う事は禁止だし、 クラスで閉じて使う分にはプロトタイプベースは見えないから問題ないだろ。 何を問題視してる? >>723 ECMAScriptの仕様書も読んだことない低脳が堂々と嘘を書くなよ ES2020の14.6.12 >>725 自己レス「ES2020の14.6.13」の書き間違い >>724 そもそもプロトタイプベースの方が静的解析難しいからちゃんと補完できるIDE作るの難しいと思うよ 例えばプロトタイプベースでtypescript作れるかというと結局クラス宣言的な物を導入せざるを得ないと思う 構文解析なんかは大して難しい話ではない 実際にTypeScriptはinterface導入してるし何も問題ないだろ >>727 最終的に何が言いたいのかさっぱり分からんが、既に言ったとおり、 IDEの都合でプログラミング言語の仕様を決めるものではない。それは逆だ。 プロトタイプベースではIDEを構成出来ないからクラスベースを導入した、と考えてるのなら、上記の通り。 IDEの為にプロトタイプベースを廃止してクラスベースに一本化すべき、でも上記の通りだし、JSでは無理。 IDEの為にクラス構文なんてそもそも導入すべきではなかった、と考えてるのなら、それもありだし個人的には賛成だが、 一般論としては現在の、メジャー言語でほぼクラス導入済みの状況で、JSだけ不採用も、メジャー言語としては難しい。 GoやRustは今も今後ともマイナー言語でしかないし、勝手にやってろでしかない。 静的解析自体はクラスの方が簡単だろうけど、だからどうしたでしかない。 実行エンジンはあるのだから、実装難易度の上限は実行エンジンを実装する程度でしかなく、出来る範囲だ。 最悪、実行エンジンをそのままコールして結果を得る事も出来る。Flycheckとかそういう構造のように見えるけど。 ちなみにTSが型を導入したのも、IDEを作るためではなく、 プログラマが型を明示的に示す事によって、間抜けなエラーを静的に検出するためだぞ。 そこにIDEが勝手に乗っかっただけであって、IDEが無くとも型の導入自体は意味も効果もある。 型無し言語出身者は型をIDEでの補完をするための物だと勘違いしてるが、そうじゃない。 >>729 言いたかったこととしてはプロトタイプベースがクラスベースの機能包含しているとしても 静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ 実行エンジンを実装してもあらゆるパスが評価できるわけでないので宣言的記法の方に軍配が上がると思うが 実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの? flycheckってemacsのパッケージのことだと思うけどあれも静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ? IDEのためだけではないというのはその通りで、途中から略して書いてしまっているが >>720 ではIDEや静的解析といっている >>730 > 静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ IDEの「実装」をプログラミング言語の「仕様」比較(スーパーセットかどうか)に含めるのがおかしい。 それは「○○は△△のスーパーセットではない。なぜなら『僕が』それを『実装』出来ないから」と言ってるのと同じだろ。 IDEは開発をサポートする道具であり、サポート対象はプログラミング言語だ。 よって、仕様上どんなに構文解釈が難しかろうが、必要ならやるしかないし、それだけだよ。 上下関係で言えばプログラミング言語の『仕様』が完全に上であって、 IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。 > 静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ? 俺が使ったのはGoだけど、見た目は実際にコンパイルを走らせてそれをアノテートしてただけ。 でも確かにこれが一番生産性が高いんだよ。 当たり前だが、コンパイラはエラー時には何行目の何文字目でこけた、という情報を持ってる。 だから静的解析が目的ではなく、ソースコード作成時にエラーを表示する事が目的なら、これでいいんだよ。 最大のメリットは構文解釈を自前で実装する必要がない事。 構文解釈機の再開発をやめ、本体コンパイラのエラー情報をより詳細に出す事にリソースを突っ込み、 IDE側はその詳しいエラー情報を解釈してアノテートするだけに徹する。 これで言語側の仕様変更に自動的に追従するようになる。 IDEの数だけ構文解釈機を再開発するのは手段が目的化してる。 > 実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの? Flycheckは外部から呼んでるだけ。でもそれでコンパイラが吐くエラー(=静的エラー)は全て検出出来る。 しかも自前の実装もなしだから、最も生産性が高い。 自前の構文解釈機でコンパイラ/ビルドシステム以上のエラーを検出する気なら、 それはIDEではなくリンターと呼ぶべきだが、 それが出来るのなら、コンパイラ/ビルドシステムにそのリンターを内包して、 IDEはそのエラーを表示する事に徹するのが最も生産性が高い。 IDEで構文解釈するのではなく、エラーを出来るだけ早い段階で検出して修正するのが目的だから。 >>731 > IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。 なぜそうあるべきなのですか? 近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね? なぜか構文解析の話になっていますが意図してたのはintellisenseのような意味解析が必要な機能です プロトタイプベースの記法では解析のためにコードの実行パスを追いかけプロトタイプの設定箇所を検出しなければならないのに対して 宣言的記法であればスコープ内のクラス宣言を見ればだいたい事足りるので実装難易度は大幅に異なるかと 今時プロトタイプベースがぁ、って言ってるのが時代遅れじゃねーの。 クラスベースじゃないからってRustやGoを出してるがそれらはプロトタイプベースですらないわけで。 >>733 >>719 はクラスベースを時代遅れと書いたんだが ぶっちゃけオブジェクト指向が過去のものになってきてるのみんな分かってるだろ >>732 > 近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが 「多い」というのならまず具体的に名前を複数挙げてみろ。 出来なければそれは君の妄想だね。 > また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね? 違うぞ。それは今の話に関係ない。(どっちでもいい) > 意図してたのはintellisenseのような意味解析が必要な機能です だから何?これも君の考えが間違ってる。 flycheckのやり方でも原理的にインテリセンスは出来るんだよ。 インテリセンスで出なかったキーワードだとコンパイルエラーになるのなら、 仮にコンパイラが無限に速ければ、ソース内の全キーワードで試せば、コンパイルが通るキーワードのリストは得られる。 実際こんな事をしてる物はないと思うが、構文解釈で100%絞る必要なんて無くて、 候補が数個程度なら全部試してエラーが出なかった物を出す程度でも十分実用的なんだよ。 今時emacsでもインテリセンスするようだから、そんなにIDEが気になるのなら、彼等のアプローチを確認してみるといいよ。 全言語向けに自前でやってる事なんてないと思うよ。 プロトタイプを自分で追うのが技術的に無理なら、evalさせてgetPrototypeOfやinstanceofを使って追えばいいだけ。 自前の構文解釈器でソースからデータツリー構築をする気だからおかしくなる。 それはevalすれば実行エンジン内に構築されるものでしかないのだから、完全に再開発だろ。 eval出来る環境があり、それが一番近道なら、やればいいだけ。 君は多分「生産性」を勘違いしてる。 むしろ再開発しすぎてるし。 現状どうなってるのか知らないのだけど、メジャーなIDE、 例えばVSCodeとかだとクラスベースならインテリセンス出来るが、プロトタイプベースだと無理とかなのか? 誰か使ってたら教えてくれ。 ×クラスベース ○クラス構文 クラス構文で書いてもプロトタイプベースなのは変わらん >>734 確かにクラスベースがってよりオブジェクト指向が時代遅れって感じだね。 JS自体は関数プログラミングもいける。 言語仕様も分かってないIDEも使ってない部外者の素人同士が長文レスバって地獄だな >>735 > 「多い」というのならまず具体的に名前を複数挙げてみろ。 例えばgolangやrustはコアチームがツール開発に積極的ですね ツールのチームがコア言語に対してフィードバックしていたりする > eval出来る環境があり、それが一番近道なら、やればいいだけ。 "構文解釈機" という言葉を使っているから静的解析を意図してるのかと思ったけど動的解析も含んで言っていたのね それで実用に耐えうる速度と精度が実現できるならそういうアプローチもありかもね それから別にIDEが自前で静的解析器を開発すべきなんて主張はしてないから藁人形論法はやめてくれ >>737 オブジェクト指向というか継承が忌避されてる気はする オブジェクト指向ならではの筆頭が継承だから継承が忌避されてる=オブジェクト指向が忌避されてるってことよ OOPLが提供していた継承以外の特性の多く(カプセル化など)は抽象データ型から来ていてそれは時代遅れになってないし忌避されてもいない クラスの定義だけど、 classとfunctionを混在した書き方でも問題ないの? >>741 混在した書き方っての次第だが class A {} A.prototype.x = () => {} a = new A() a.x() こんなのは当たり前に動くぞ つかまずは自分で試せよw JSなんかブラウザあれば動かせるんだからさー >>739 > 例えばgolangやrustはコアチームがツール開発に積極的ですね それで、それらの言語のどの仕様がIDEの都合で採用されたものなの? > 藁人形論法はやめてくれ なら最初から分かるように主張しろ。 何が言いたいか分からないからエスパーして複数挙げてみただけ。 馬鹿は無視してきっちり自分の意見を書ききれ。 3行しか読めない馬鹿はプログラミングなんてどうやっても出来ない。 MDNその他のリファレンス見りゃ分かるが、そんな世界じゃない。 5ch程度の文にすら手こずるようではどだい無理だよ。 解釈が動的か静的かは意味無い。 出来るだけ早い段階でエラーを検出して修正したいだけであって、それが出来れば何だっていいんだよ。 その手段の一つが静的解析でソース作成時にエラーを表示する事であって。 でも、エラー表示だけなら、コンパイラやevalにぶち込めば出来るし、それをやってるっぽいのがflycheck。 構文解釈器を自前で作るとしても、クラス構文でもプロトタイプ構文でも、大して難易度は変わらない気もするが。 実際に問題になるのは、構文解釈そのもの、具体的にはJS的な様々な書き方でも問題なく動くパーサの構成だろ。 構文解釈後の親class/プロトタイプ追跡なんて辿ればいいだけだからアホでも出来る。 それで今時のIDEで実際どうなのか聞いたんだよ。 もしプロトタイプ構文ではインテリセンスが動かないのなら、何か理由はあるのだろうけど。 継承が忌避されてるのは、JAVAでは関数ポインタが使えず、同様の事をするためには継承をこねくり回すしかなくて、 それの残骸がデザインパターンなのだが、 結果、継承すべきでない局面での継承で酷い事になってるからだよ。 でも、継承すべき場所では継承した方がよくて、全部捨ててるGoはいちいち全部書かないといけないのが糞。 あれは1周目はまだしも、2周目以降でそのコピペされたソースにメンテコストがかかるから、先すぼみになると予想してる。 Rustはやってないから知らん。 何言ってるか分からない相手にエスパーして反論って藁人形そのもので完全に異常者 いい加減スレチだから他所でやってもらえんかね このスレ伸ばすにしてもnodeにScheduling APIが入ったとか普通にネタあるだろ 最近アツいサーバサイドJSはnodeよりもdenoよりもCloudflare Workers denoは苦戦してるみたいだねー それでexpressなどnode用のライブラリが動くように互換性を高める方針になった でもそれならnode使い続ければいいやってなりそう puppeteerを使って投票サイトの投票を自動化したいのだけど、 実行してもエラーを起こさず無反応なんだよね Headless Recorerを使ってるからHTML部分の間違いはないと思うのだけど、 UserAgent以外で何か対策ないっすかね いくらでも試すことはあるけど悪事の片棒を担ぎそうで怖いな 一般論として言えるのはpuppeteerでも普通にWebページのコンテキストからDOM APIを叩ける んじゃ、逆にWEBサイトを作る側はどんな対策をしているのでしょうか? >>752 使ってるところは諦めてるんだけど、使ってないところはどうやってるのかな〜と思って UserAgentをガラケーにしてみたり、プレステにしても無反応なんだよね 手動で操作した時のリクエストヘッダーの中身を解析して 間違いなく妥当なリクエストが投げられてるのが大前提 あとは“how to detect headless browser”でググるといいよ npmがぶっ壊れたらどうすればいいですかapt でuninstall installしても治りません スレ立てるまでもない質問はここで 158匹目 https://mevius.5ch.net/test/read.cgi/tech/1635193843/538 ここに、YouTube で有名な、雑食系エンジニア・KENTA のサロンの、 Ruby on Rails 初心者用コースの内容を書いておいた 基本的に、Rails以外のフレームワークは、シェアが少ないのでおすすめしない。 学習環境も揃わないので、無理 Railsでは、Railsチュートリアル・Railsガイド・ 黒田努の3冊の本・パーフェクト Ruby on Rails・Ruby on Rails 6 エンジニア養成読本とか、 Rubyでは、改訂2版 パーフェクトRuby・改訂2版 Ruby逆引きハンドブックなどの教科書が揃っている これほど、良い教科書が揃っているフレームワークはない! Laravel のシェアは少しあるけど、KENTAがPHP は一生やる必要がないと言ったので、 PHP自体がオワコンになってしまったw 日本のウェブ開発の将来は、ほぼKENTAが決めている。 Scala を滅ぼしたのも、KENTA for await (const chunk of stream(foo)) { response.write(chunk); } response.end(); ↑みたいな感じでレスポンスに直接書いてってるやつって、一旦に変数に入れることって可能? const chunks; for await (const chunk of stream(foo)) { // chunksにchunkを書き込んでいく } response.write(chunks); res.end(); ↑こんな感じに書きたくてさ レスポンスのサイズを減らしたくてzlibのコード見たらレスポンスを直接圧縮するんじゃなくて、オブジェクトを圧縮してそんでレスポンスにパイプって感じに見えたもんで ただ書き方がよく分からんくてね そんな感じのコードでやれると思うけど ただ局所的な負荷を避けるStreamの利点が消えちゃうぞ > レスポンスにパイプ stream.pipeline()関数を使えってこった >>757 chunksに貯め込んでからzlib.gunzip()やzlib.inflate()を呼んでいたらメモリの無駄遣い そこでzlib.createGunzip()やzlib.createInflate()で変換用streamを作って使う それも昔はinput_stream.pipe(transform_stream).pipe(ourput_stream)と多段に繋げていたが しかし速度差がある時のバッファリング問題もあるため一気に協調させることになり 今はpipeline(input_stream, transform_stream, ourput_stream, cb) と好きなだけ並べて書く 758 759 760 ありがとう pipelineってやつ使うとよいみたいやね 調べてみますわ なんでchildprocessのイベントにはSIGINTが実装されてないんだろ それでいて親から伝搬はするからdetached入れて切り離さないと落ちちまう 親同様にリスナー付けてexitを止められるようにするべきだと思うんだが 相対パスでローカルモジュールをnpm iするとdependencieではfile:から始まる相対パスになるけど 実際これは完全に無視されて同時に作成されるnode_modules以下のsymlinkが読み込まれるんだな なんでこんな実装になってんだ いや更新時の参照用ならこれでいいのか nodeのrequire/importとnpmのinstall/updateを混同してたわ read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる