shama/nodewebkit

Proposed plan to remove complexity in the installer version handling

jamesmortensen opened this issue · 2 comments

jamesmortensen commented

Problem Statement

Currently, when a new version of node-webkit is released, the package maintainers must release a new version of the nodewebkit installer in order for developers to use it in their applications. This creates the following problems:

  • This creates more work for the maintainers.
  • This means a longer wait for developers interested in obtaining the latest version, or it means they're forced to subvert this tool's normal install process.

I also don't work alone. We have non-technical and junior developers who test and contribute to the application, so something seemingly as simple as a wget to many of us in the open source world can feel complex and harrowing to such folks not immersed in the tech world. In short, subverting the install process reduces our productivity.

I propose the following improvement to reduce complexity:

Solution Overview

Instead of basing the version of nodewebkit off of the version of the installer, is it possible to modify the actual nodewebkit installer command line tool so that it runs independently of npm install. Using something like commander, would it be possible to read command line arguments? This eliminates the dependency on the installer version number.

Proposed Usage:

Step 1: Install the nodewebkit installer. This step doesn't install node-webkit! It only installs the installer:

$ npm install -g nodewebkit    # install the nodewebkit installer, but don't install nw yet.

Step 2: Invoke the installer with a command line argument, which tells the installer to download the correct version of node-webkit:

$ nodewebkit install 0.10.2

The install <version_number> arguments would do the following:

  • Detect the platform (osx-32, win-32, linux-32, etc).
  • Read the target version number from the argument list.
  • Download the target version and platform from http://dl.node-webkit.org and install it, using the existing, tried and tested process.

Possible Advantages:

The process of installing node-webkit is -- as a general rule -- the same from version to version. It's only the version number that differs. Modifying the process, as outlined, has the following benefits:

Possible Downside:

The potential downside to this approach is that it creates an additional step for those people installing dependencies via npm. They would run npm install to install their package.json dependencies, and then they would run the nodewebkit installer separately. However, this is still much simpler than manually grabbing node-webkit from the download server, especially when working with non-technical early-adopters and junior developers/testers.

Conclusion

I hope these ideas help improve this helpful tool. If this sounds like a good plan and is something you would support, I may be interested in contributing by forking and doing a pull request (if it isn't something you have time to do). Please let me know what you think!

shama commented

Thanks for the detailed proposal!

It is versioned the way it is to allow those adhering to semver to manage their dependencies with npm. So unfortunately turning this library into an installer won't integrate with npm. For example, if I have a module that depends on nodewebkit, how would that module define which compatible version of nodewebkit should be installed as the module is installed?

I think if an app needs a tool to download node-webkit or multiple versions or copies for different platforms they should use something like node-webkit-builder instead (or their own tooling that wgets or something).

jamesmortensen commented

I didn't think about module dependencies, and that's a good point. Fortunately, it's not something I've yet encountered when dealing with node-webkit. We try to use the latest version of everything.

I'll try out the other options you identified. Thanks again for the quick response! :)