Running JSBin Local

I'm a big fan of JSFiddle, but unfortunately, being a SaaS solution, I can't run it local on my laptop for those situations where internet isn't an option.     I started looking at some alternatives, such as the older jsbin.    jsbin is both open source and SaaS.  However it does have one big issue, it doesn't install well on ANY operating system with the latest version of Node.jsand npm.

I spent hours trying to get everything running, first I tried Windows after making sure I had all the development dependencies in place, Visual Studio, the correct version of .Net Framework, the sdk's and so forth and then the latest version of NodeJS and npm.  Then following that which what should be the easiest install (In administrator mode)   npm install -g jsbin.

ERR!

First, there are a couple (maybe more) issues with Node.js, and npm on Windows.

First is the rather onerous task of getting all the Windows development pre-reqs in place just so the  node-gyp add-on build tool is in a somewhat workable state.

Second is the default usage of using the users AppData/Roaming folder for npm modules.  This particular folder has policies applied that npm just doesn't like, such as CryptoLock prevention (at least on my system).  Which is a good thing, given some of the security issues with NodeJS currently, but it's a mish-mash of configuration settings trying to set up NodeJS/npm to use something other than that folder, setting the prefix and so forth.

After going down that rabbit hole, I opted instead to fire up a vmware of the debian sort; Mint KDE.  Which has most of the development dependencies already there.  MySQL and MySQL Workbench installed without any issues with openssh-server, and easy installation of the others through apt-get along with the added benefit of being sandboxed and snapshots.

Again,  sudo apt-get install nodejs, sudo apt-get install npm, sudo npm install jsbin

ERR!

The solution,  uninstall nodejs (or in my case revert snapshot), sudo  apt-get install nodejs-legacy (which uses a symlink) , sudo apt-get install -g npm, and then sudo npm -g install jsbin.

and then the crossed finger moment: jsbin....

Success.  

The next step is to try and make mods to the jsbincode. The github jsbin repo  doesn't build currently so more troubleshooting.  I still need to update the resource strings to point to the local versions, with expansion of some newer js and css libraries, which I'll place on the VM Nginx.   o

I know the folks over at jsbin don't have a lot of incentive to update their open source project and instructions to the latest Node.js and npm since they have a paid model, but I sure wish they would.

NPM and Security

So I decided to expand my learning a bit with npm and just as I start diving into it,  lo and behold, one of the major tenants of Open Source has been abused, "Trust".  An individual unpublished a bunch of their popular modules, which promptly broke a many developer builds.    Not only did this cause an uproar, but also some serious discussions about the inherent security issues of the current npm community process.    

Right now it's very easy for a npm newcomer to just run "npm install some_package" that was previously a trusted source, but is now compromised and end up with nefarious code that could seriously affect their system.  If you work with github at all, you might download a project that has many npm module dependencies, enough that going through a serious code review before you try to launch it would take a considerable amount of time.  

IMHO, here's what I think needs to happen, assuming it can be communicated effectively with enough advanced warning.  Admittedly, I'm very new to npm, so some of my suggestions may not be perfectly tuned, so please forgive me. 

• On npmjs.com, make it easy to flag a module that has an issue.  You have to be a member to flag and set a threshold on the number of flags before it's deactivated and sent for review.  Additionally add a new parameter to the npm config that enables the npm install to ignore flagged modules with a level threshold setting.    Typical warning messages would occur on install of a flagged module.
• Consider changing  --ignore-scripts   to --enable-scripts with a configuration setting that can be changed to the old behavior.  

• Breakup the main repo into multiple repos consisting of;
• Core modules that are provided by the npm team.   Other npm modules could be added to the core only through a vetting process after submission by the author.  Once submitted and included, all rights transfer over to the npm team.
• Move all other modules to a developer  repo, also owned by the npm team.    A developer would need to specifically add that repo to their configuration.