【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
package.jsonの"scripts"に書いたコマンドをnpm runで実行する際はnode_modules/.bniがPATHに 追加されますが、これ以外に任意のディレクトリをPATHに追加する方法ってあるでしょうか。 windowsだからpythonのpip以上にnpm厄介だな ありがとうございます。でもwindowsだとうまくいかないなぁ。 "somecommand": "set PATH=%PATH%;<パス> && <コマンド>" #<コマンド>は内部でPATH環境変数を使用するスクリプトで、これ自体にはPATHが通っている。 &&の両側のコマンドが同時に立ち上がるんだから当然と言えば当然か。 でもコマンドプロンプトで順次実行する&に変えても結果は同じだった。 bashのexportみたいなのが使えればいいんだけど。 めんどくせぇなぁ、 そのためのnpmライブラリでもあんだろ 他にnpm-run-allとかrimrafとかあればwinでも動くnpm scriptsが書ける ありがとうございます。cross-envでいけました。 node.jsでimportを使うと SyntaxError: Unexpected token import ってなるんですが、importに対応したnode.jsはまだ出てないのでしょうか? >>571 importの使い方を聞いていません babelとwebpackでimport書いてるので使い方は知ってます node.js自体がimportを実装しているのかを聞いています *.mjsからはimport出来るようにしようぜ ってのを結構前に読んだ気がするけど、まだ実装されたないんか? 実装どころか提案文書はドラフトのままだよ (技術的検証が済んでACCEPTされないと実装に進まない) 検証だけであと1年以上掛かるってさ なお拡張子(*.mjs)でES moduleかどうか判別する手法は 考え得る限り最低の糞という判断が下されたので無くなる そこはESの管轄外だよ NodeがWebと合わせる必要もない いやnodeってv8使ってる立場だから何もできんでしょ 間違ってる? v8はネットワークもファイルシステムも持ってないからimportは環境(ブラウザやnode)に丸投げでしょ Buffer.byteLengthをブラウザ側でも利用できるように移植して欲しい 今時バイトでカウントするにも自力でコード書かないといけないのは無駄すぎる importはJavaScript(EcmaScript)の仕様範疇の中に入れてもいいが、 ブラウザで動かすJavaScriptにおいて、 importはビルド時に解決する問題になるんだよね。 なぜならファイルのアクセス数が増えてパフォーマンス低下につながるから。 JavaScriptファイルを結合することでパフォーマンスをあげるという目的があるから 結合させずに動いたとしても、ビルド時に結合させるという手段は今後も続く。 ウェブサーバーのプラグインでJavaScriptファイルをimport定義に従って 結合するという仕組みができるかもしれないがこれもビルドを配信時に行うってだけ >>581 ブラウザ側で実装する or 自力でコードを書く の中間に、ライブラリを使うという方法があるよ。 この方法を使えば、既存のブラウザでも動くし 自力でコードを書くムダもない 自力でコードを書けるたぐいのものなら、ブラウザに移植してほしい理由を言うとしたら 「ネイティブで実装されていれば速い可能性がある」であるべきだろう >>582 すごく巨大なファイルへのアクセス数でパフォーマンス低下するか、 CDNで配信されてて、もうすでにブラウザキャッシュに存在するかだと、後者の方が速いと思うけど。 すごく巨大なファイルもCDNで配信されブラウザにキャッシュされるだろw >>586 コネクションが再利用されるとしても、 ファイル要求は別に行われるだろうが 要求されるまでもなくプッシュできる キャッシュとの絡みで今んとこ絵にかいた餅だが ふーん そういう妄想は同人誌即売会で売ってるといいよ それよりもminifyが未だにes2015を正式対応してないの早くなんとかしてほしい。ブラウザがes2015サポートしてても結局es5で吐き出してる babel使えば? babel自体にminify入ったろ? >>591 おー。愚痴ってみるもんですな。 typescript使ってたんだけどbabel挟んでみようかな。 typescript使ってるならビルドした後minifyすればいいだろ jsでデスクトップアプリケーションが作成できるelectronでソフトを作りたいのですが、 http通信のためのモジュールであるrequestモジュールを、main processからrequireするといろんなプロパティを持ったオブジェクトが返ってきてその中の関数でhttp通算できるのですが、 renderer processからrequireするとただのrequestという名前の関数オブジェクトが返されるだけで使い物にならないです。 pc通信でrenderer processからmain processにhttp通信を代行してもらうしかhttp通信をrenderer processで扱うための方法はないですか? >>595 renderプロセスはブラウザと同じなのでfetch使えばいいですよ >>598 そりゃサポートはされるだろ 結合しないと遅いってだけなんだから >>599 モジュール化するほうがファイル増えて遅くなりそうなんだが >>600 だからwebpackでビルドして結合するんだよ >>582 > ウェブサーバーのプラグインでJavaScriptファイルをimport定義に従って > 結合するという仕組みができるかもしれないがこれもビルドを配信時に行うってだけ 事実誤認も甚だしい パックする仕組みは配信からの要求で考えられた それをトランスパイルとかいう歪な仕組みを進めている連中が取り込んだだけ 逆だね >>602 うん だからhttp配信という構図だとパックする必要があるからimportがあまり意味がないというのは間違ってないとおもうんだが 正しいか正しくないかでなく 自分が最後に喋って締めないと気が済まない人種というのがいるのだ マウンティング症候群を併発していることが多い ようするにキチガイ >>605 それって相手もそうじゃないとそんな状態が発生しなくね どっちかが最後にレスしなくてもいいと思ってるならいつまでも会話続かなくね >>607 自分はするけど相手がするのは許せない人なんでしょ 初めてインストールする初心者なんですが、インストールしようとすると 下記エラーが出てインストール出来ません。 There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. 色々ググってみましたが解決方法がさっぱりです。 どなたか対処方法をご存じでしょうか? ご意見を戴ければ幸いです。 検索すると解決法がでて来てるじゃん それをやったけど解決しないというのか? それとも検索する能力がないのか? はっきりしろ >>614 その通りです。英語どころか日本語にすら不自由しているバカです。 よろしければ解決方法をお教え戴けないでしょうか? >>615 win版はとにかく問題がおおくMSが公式にインストール順序公開してたぞ ぐぐってみろ >>617 npm5も yarnよりは遅いけど高速化&lockファイル追加 つーかむしろリリース早くないか? どうしちゃったの最近 いやん、6にしなきゃなぁと思ってたら8がでちゃったよ おれ4のまま使ってるんたけど6とか8は何が違うの? スーパーサイヤ人だとフリーザしか倒せないけど スーパーサイヤ人2ならセルまでなら倒せるぐらい >>625 なるほど ところで下位互換は保たれてるんだろうか? async/awaitとかの大抵の機能はnodeのバージョンアップしなくてもbabelとかtypescript使えば古いバージョンでも使えるよ >>628 これ。typescript使ってるから正直どうでもいい。 >>629 ts2.1でtarget es5でも使えるようになったしな nodeって起動するだけでメモリ相当食うから、バージョンアップでさらに増えてないかが気になる 安いプランのVPSだとメモリ1Gとかだから >>631 node起動するだけなら7MBしか食ってなかったぞ? >>632 v8が起動するんだからそんな少ないわけないだろw >>633 こんな感じのようだが? http://qiita.com/shouta-dev/items/09d7055329710684d9c7 > process.memoryUsage() { rss: 9019392, heapTotal: 5115392, heapUsed: 2658096 } そりゃnode.js内のメモリ消費量でねーの ランタイム内のプロセスと実行環境自体のプロセスを混同させるような>>634 もアレだがな だからWeb屋は ちょっとしたサービス作って待ち受けするだけで普通に数百MBは食うぞ ちょっとしたサービスなら200MB台で済んでる気が >>637 うん、実際そんなもんだよ サービスによりけりだけど単位は百MBにはなるね >>639 nodeやるなら512は実用的じゃないと思う ssdならスワップ早いからなんとかいけるかもしれんが最低でも1GBは欲しい >>640 node起動するだけなら7MBしか食ってなかったぞ? nodeは依存関係の関係でアホみたいにモジュールロードあるからね >>641 条件は「nodeを起動するだけ」なんだからその程度だろうね。 >>642 そりゃexpressとか動かせばその分のメモリ食うさ でもそれはrailsとかでも同じなわけで、なんのモジュールをロードするかとか 言ってない上、nodeを起動するだけのメモリ使用量しかわかるわけがない >>644 何も言い返せないなら黙っていたほうが良い 7MB君ってほんとうにおめでたい脳味噌してるんだな >>643 socket.ioのみの簡単なサービスですら200M越えるんだが? 君はどうやって使用メモリを調べてるのかな?ん? linuxコマンドでも書いてごらん >>631 の文脈からして何らかのサーバー立てるんだからnode単体の話をするのは空気読めてないよね >>648 おまえはVPS借りてnode動かすのに何のサーバーもたてないつもりかな?んー? で? 検証用のコードと7MBの確認コマンド公開まだかな? 649はレス相手間違えた この期に及んでnode単体という屁理屈で逃げてるやつは回答まだかな? >>647 たった5行でWebサーバーが書ける http://engineer.recruit-lifestyle.co.jp/techblog/2015-06-22-node1/ httpモジュールを使っている分、nodeだけのメモリ使用量ではないが、 ps uのRSSの値は26000KB、つまり26MBだが? >>649 > おまえはVPS借りてnode動かすのに何のサーバーもたてないつもりかな?んー? サーバーたてなくてもコマンド実行するという使い方もあるだろ? > nodeって起動するだけでメモリ相当食うから、バージョンアップでさらに増えてないかが気になる > 安いプランのVPSだとメモリ1Gとかだから >>631 の文脈から言って、メモリを相当食う何かを動かしているのだろう。 だがそれはnodeの使用量ではなく、モジュールの使用量がほとんど。 nodeのバージョンアップでメモリ使用量が増えたとしても 大部分のモジュールの使用量は変わらないので、気にするレベルにはならない。 メモリの使用量を抑えようと思ったら何を使うのが一番いいんだろうな。 やっぱgoとか? v8ってandroidでも動くようにしてるんだよね。新しいバージョンのほうが省メモリの可能性ないかな。 android goとか出してるわけだし v8のignitionは省メモリ、スモールフットプリントのためだから可能性は十分よ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる