Release of the second version of the Nodejs plugin for Sublime Text

Good afternoon friends! In November 2016, I started playing with Nodejs plugin for Sublime Text. The plugin was small and had several old and well-known bugs under the cut.

In those days I was playing with Nodejs and my favorite code editor was Sublime Text. On the long-beaten track, I went to packagecontrol.io and looked for Nodejs plugins. I found this one . Having put and worked, I was very disappointed when I found out that some of the declared features of the plug-in do not work, or do not work as stated ...

In such situations, I usually go to the project page on GitHub and study the project for last activity to make sure that the project is not abandoned. I found that the last commit was in 2013. Pechalka, I thought, considering that this was the only plugin for working with Nodejs in Sublime Text.
')
Then I thought ... These are two pieces of technology that I like, and I always wanted to contribute to Open Source.

The plan was simple, fix the bugs that I face. Over time, I realized that fix bugs began to cause problems, due to the monolithic architecture of the plugin, the lack of tests and tools for debugging.

Plans change

As I mentioned earlier, I suffered from a lack of tests and debugging tools. Fixing one bug could cause a series of other bugs. Moreover, fix bugs on some platforms, could cause or leave bugs on other platforms. Then, it was decided to make life easier and happier. =)

What was done

A lot of things were refactored, redone and rethought. All changes can be logically divided into two groups: user interaction with the plugin and developer comfort.

Developer Comfort

I will present everything in the form of a list with a small explanation of why, as well as maybe why it was done.

• All code base of the plugin in earlier versions was located in one Nodejs.py file. Logically, the division of a monolithic file into logical modules and the transfer of all this stuff into the lib folder is requested . Now we have the following logic modules:
  
  • nodejs_base.py - base classes for commands - in terms of Sublime Text
  • nodejs_command_thread.py - classes for running OS specific processes
  • nodejs_commands.py - classes that make up the core of the plugin
  • nodejs_constants.py - several PLUGIN_PATH type constants, etc.
  • nodejs_debug.py - debugging functions
  • nodejs_nvm.py - class for defining and working with NVM
• Added debugging functionality. Throughout the code, you can call the debug function to display any debugging information in the Sublime Text console. The data will be displayed if there is a file in the plugin directory named .debug_plugin . Accordingly, to turn off the debug information you just need to delete the file.
• Added the ability to test, thanks to the excellent work done by Randy3k . This great plugin allows you to write acceptance tests for Sublime Text plugins. Basically, it is a unittesting module from the standard Python library, so you can write simple unit tests for the key functionality of your project.
• The module of the aforementioned Randy3k also has the functionality and side code for running tests in CI (continuous integration) services, such as Travis CI and Appveyor. Due to this, it is now possible to test the functionality of the plugin on all platforms.
• The plugin now depends on the modules: shellenv and newterm , which means that after installing the plugin, you will have to restart Sublime Text, unless of course they have already been installed with other plugins.

With the help of all of the above, now we can fix bugs or add new functionality, enjoying the process.

User interaction with the plugin

So, we got to the most interesting part - the user interaction with the plugin. As in the previous part, I will list the list of changes and the reasons for this.

• Fortunately or unfortunately, the plugin now supports only the third version of Sublime Text. The reason for this was the long-awaited, non-beta, release of the third Sublime Text, as well as the use of Python 3-specific functionality in the code.
• Probably the most annoying problem (only when I had 3-4 bugs on the GitHub) is the incorrect operation of the autocomplete. At times, autocomplete replaced part to point: os.chdir () ,
  chdir () replaced the os part. Time autocomplete duplicated part to the point: http.createServer ()
  duplicated part of http , it turned out http.http.createServer () . The problem was solved by making changes to the tools / docs_builder.js , by adding the names of the modules of the standard Nodejs library as separate elements of the autocomplex.
• Now when loading the plug-in, it determines whether NVM is installed, and if so, it uses the version of Nodejs from NVM.
• Also, when loading the plugin, it generates autocompletes for the currently used Nodejs version in your project.
• Now when loading the plugin, it automatically installs the dependencies for the tools inside the plugin: doc_builder.js and uglify_js.js . Previously, you had to manually run npm install after installation
• Plugin in kernel, now recognizes different versions of Nodejs. At the time of refactor 6, the Nodejs branch and the 8th branch, also known as LTS and current stable.
• Plugin settings now open in Sublime Text 3 style using the edit_settings command. Left default settings, right user settings.
• Plugin commands are now active (can be run) for buffers / files of type source.js
• Tax. What is the most important tool of any developer? You're right! This is a debugger.

Debugger

In previous versions of the plugin, the Nodejs Debug (+ arguments) command ran the current file with the debug parameter passed to the node . It was useless. Starting with Nodejs version 6.3.0, debugging is supported using the Chrome DevTools debugger. Read more about this in Paul Irish's blog.

Now, when you run the Nodejs Debug (+ arguments) command, the current file will be launched with the --inspect = localhost: 60123 - debug-brk option for the 6th Nodejs version and with the - inspect-brk = localhost: 60123 for the 8th option version. As you can see, the debugger runs on port 60123, which does not conflict with the default port 9229.

Next, you can connect to the debugger using the steps displayed by the plugin:

Debugger is successfully started at localhost: 60123.

1. Now you can open Google Chrome and navigate to chrome: // inspect.
2. Then click Open dedicated DevTools for Node.
3. After click Add connection to localhost: 60123

What should be done

• Recreate the functionality of the console debugger Nodejs using the module - sublime-pexpect , which I recently added to packagecontrol.io
• Monitor the processes launched by the plugin and kill only them in _kill_node_processes () . For these purposes, it is necessary to use another sublime-psutil module , which will soon appear on packagecontrol.io too.
• Run current file in terminal