【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>559
結局はそうだよな
完全な答えがあるものじゃないし 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は何が違うの？ スーパーサイヤ人だとフリーザしか倒せないけど
スーパーサイヤ人２ならセルまでなら倒せるぐらい >>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は省メモリ、スモールフットプリントのためだから可能性は十分よ ■ このスレッドは過去ログ倉庫に格納されています
