当時、私はNodejsで遊んでいて、コード用の私のお気に入りのエディターはSublime Textでした。 長い間、私はpackagecontrol.ioに行き、Nodejsのプラグインを探しました。 これが見つかりました。 設定して動作しましたが、プラグインの宣言された機能の一部が機能しない、または述べられているように機能しないことを発見したとき、私は非常に失望しました...
そのような状況では、私は通常GitHubのプロジェクトページに移動し、プロジェクトが放棄されていないことを確認するためにプロジェクトの最新のアクティビティを調べます。 最後のコミットは2013年であることがわかりました。 これがSublime TextのNodejsで動作する唯一のプラグインであることを考えると、悲しみは思いました。
その後、私は考えました...これらは私が好きな2つの技術であり、私は常にオープンソースに密輸したかったです。
計画は単純で、遭遇するバグを修正しました。 時間が経つにつれて、プラグインのモノリシックアーキテクチャ、テストおよびデバッグツールの不足により、バグの修正が問題を引き起こし始めることに気付きました。
計画は変化しています
前述したように、テストとデバッグツールの不足に悩まされていました。 1つのバグを修正すると、他の一連のバグが発生する可能性があります。 さらに、一部のプラットフォームでバグを修正すると、他のプラットフォームでバグが発生したり、残される可能性があります。 それから、人生をもっと楽にし、幸せにすることが決定されました。 =）
何が行われた
多くのものがリファクタリングされ、やり直され、再考されました。 すべての変更は、論理的に2つのグループに分けることができます。プラグインを使用したユーザー操作と開発者の快適さです。
開発者の快適さ
リストの形ですべてを説明しますが、これが行われた理由、方法、およびおそらく理由についても簡単に説明します。
- 以前のバージョンのプラグインのコードベース全体は、単一のNodejs.pyファイルにありました。 論理的には、モノリシックファイルを論理モジュールに分割し、これらすべてをlibフォルダーに転送するよう要求します。 これで、次の論理モジュールができました。
- nodejs_base.py-コマンドの基本クラス-Sublime Textの観点から
- nodejs_command_thread.py -OS固有のプロセスを起動するためのクラス
- nodejs_commands.py-プラグインのコアを構成するクラス
- nodejs_constants.py -PLUGIN_PATHなどのいくつかの定数
- nodejs_debug.py-デバッグ関数
- nodejs_nvm.py -NVMを定義および操作するためのクラス
- デバッグ機能が追加されました。 コード全体で、 デバッグ関数を呼び出して、デバッグ情報をSublime Textコンソールに出力できます。 プラグインディレクトリに.debug_pluginという名前のファイルがある場合、データが表示されます。 したがって、デバッグ情報をオフにするには、ファイルを削除するだけです。
- Randy3kによって行われた優れた作業のおかげで、テストする機能が追加されました 。 この素晴らしいプラグインを使用すると、Sublime Textプラグインの受け入れテストを作成できます。 基本的に、これはPython標準ライブラリの単体テストモジュールであり、その結果、プロジェクトの主要な機能の簡単な単体テストを作成できます。
- 前述のRandy3kのモジュールには、Travis CIやAppveyorなどのCIサービス（継続的統合）でテストを実行するための機能とサイドコードもあります。 これにより、すべてのプラットフォームでプラグインの機能をテストできるようになりました。
- プラグインは現在、モジュールshellenvおよびnewtermに依存しています。 つまり 、 もちろんプラグインをインストールした後、Sublime Textを再起動する必要があります。
上記のすべてで、プロセスを楽しんでバグを修正したり、新しい機能を追加したりできるようになりました。
プラグインとのユーザーインタラクション
そこで、最も興味深い部分に到達しました-プラグインとのユーザーインタラクションです。 前の部分と同様に、変更のリストとその理由をリストします。
- 幸運にも不幸にも、プラグインは現在Sublime Textの3番目のバージョンのみをサポートしています。 この理由は、待望のベータ版ではない3番目のSublime Textのリリースと、コードでのPython 3以降に固有の機能の使用でした。
- おそらく最も厄介な問題（GitHubに3〜4個のバグがあった場合のみ）-オートコンプリートが正しく機能していません。 時々、オートコンプリートはパーツをポイントに置き換えました： os.chdir（） 、
chdir（）はosの部分を置き換えました。 ポイントまでの自動時間複製部分： http.createServer（）
http部分を複製し、 http.http.createServer（）になりました 。 この問題は、標準のNodejsライブラリのモジュールの名前をオートコンプリートの個別の要素として追加することにより、 tools / docs_builder.jsを変更することで解決しました。 - プラグインをロードするときに、NVMがインストールされているかどうかを判断し、インストールされている場合は、NVMのNodejsバージョンを使用します。
- また、プラグインをロードすると、プロジェクトで使用されているNodejsの現在のバージョンの自動コンパイルが生成されます。
- プラグインをロードすると、プラグイン内のツールdoc_builder.jsおよびuglify_js.jsの依存関係が自動的にインストールされます。 以前は、インストール大使は手動でnpm installを実行する必要がありました
- カーネルのプラグインは、異なるバージョンのNodejsを認識するようになりました。 リファクタリング6の時点で、Nodejsブランチと8番目のブランチ（LTSおよびcurrent stableとも呼ばれます）。
- edit_settingsコマンドを使用して、プラグイン設定がSublime Text 3スタイルで開くようになりました。 デフォルト設定は左側にあり、ユーザー設定は右側にあります。
- source.jsタイプのバッファ/ファイルに対してプラグインコマンドがアクティブになります（実行可能）。
- ダックスフント。 開発者にとって最も重要なツールは何ですか？ あなたは正しいです！ これはデバッガです。
デバッガー
プラグインの以前のバージョンでは、Nodejsデバッグ（+引数）コマンドは、 nodeに渡されたデバッグパラメーターで現在のファイルを実行しました。 役に立たなかった。 Nodejs 6.3.0以降、Chrome DevToolsデバッガーを使用したデバッグがサポートされています。 これについては、 Paul Irishのブログで詳しく読むことができます。
これで、Nodejsデバッグ（+引数）コマンドを実行すると、現在のファイルがオプション--inspect = localhost：60123 --debug-brk for Nodejsのバージョン6とオプション--inspect-brk = localhost： 8の60123で起動されますバージョン。 ご覧のとおり、デバッガはデフォルトのポート9229と競合しないポート60123で起動します。
次に、プラグインによって表示される手順を使用してデバッガーに接続できます。
デバッガーは、localhost：60123で正常に開始されました。
1.これで、Google Chromeを開いてchrome：// inspectに移動できます。
2.次に、Nodeの専用DevToolsを開くをクリックします。
3. [接続の追加]をクリックして、localhostへの接続を追加した後：60123
なすべきこと
- modulecontrol- sublime-pexpectを使用してNodejsコンソールデバッガーの機能を再作成するには、最近packagecontrol.ioに追加しました
- プラグインによって起動されたプロセスを追跡し、 _kill_node_processes（）でそれらのみを強制終了します。 これらの目的のために、別のsublime-psutilモジュールを使用する必要があります 。このモジュールは 、 まもなくpackagecontrol.ioにも表示されます
- ターミナルで現在のファイルを実行する