Ability to launch SourceJS via NodeJS Script

[Alanoll]

Problem: If I have a NodeJS application, attempt to perform a require(sourcejs) so I can script and debug using VS my site's code (or any SourceJS plugins), I receive multiple errors.

I've been using the following setup for my SourceJS site development:

• Visual Studio 2015
• NodeJS Tools for Visual Studio

I created a "Javascript Project" in Visual Studio, so I can add the site to my group's build chain, and then also have a separate repository containing just my site's specs, and not the SourceJS source.

My NodeJS package.json includes just the single dependancy for sourcejs, so I can then perform an npm install to quick install my site for development/production.

[Alanoll]

I've got the issue fixed, and just following the contribution.md steps. If I screw up the process, let me know and I'll be sure not to do it again.

[robhrt7]

Hi,

Thanks for your input and patch suggestion. I will look deeper into the changes, to validate the proposed solution.

[robhrt7]

Have you tried spawning sub-process from your node script, instead of calling sourcejs server function directly? This will ensure that SourceJS will be isolated from your parent application, and also will enable it running on a separate CPU thread,

[Alanoll]

@operatino
I actually tried two different approaches, both work:

• I used child_process to spawn a new process (like you suggested)
• I used global-npm to launch the process

Both achieve the same child process launch and it works.

In my scenario, the child process would just add more overhead. My application, is truly just a stub to spin up the SourceJS server at the moment:

(require('sourcejs/app.js')();

My ultimate end goal is to have this NodeJS application hosted by IIS via iisnode.
Primarily because this won't be my our documentation/resource server (API docs, internal docs, etc), and it'll be more end-user friendly if they just navigate to a single server, and not have to worry about ports to see each site.

Since iisnode launching Node as a separate process (indeed it can even pool them), the child process route will cause a secondary process to launch that then runs SourceJS.

[Alanoll]

What if the start function was expanded to take in an options objects that could act as another way to configure the SourceJS server (like the command-line arguments)?

[robhrt7]

Hm, in case you don't have anything in you parent application, why do you even need to call SourceJS as a function? I haven't worked with iisnode, but 0.6.0-dev version is completely compatible with other PaaS like heroku.

Usually those remote runtime environments just call npm start or whatever you define as a starting commang + set some environment.

[robhrt7]

Here's also an example of the recommended (and only flow for 0.6.0) of starting SourceJS https://github.com/sourcejs/init/blob/npm/package.json. Could be that you've been looking into an old structure, where indeed the SourceJS code was a part of local project.

Please try playing with this installation flow https://sourcejs.com/docs/base/#from-npm, and see if you still need to call SourceJS server as a function, or having an npm script to run it is enough.

[Alanoll]

I started with 0.5.6--nojsdom (Windows), and then upgraded to 0.6.0 (nightly.6) because of a couple other bugs.

I actually already had the npm start script in my package.json for my project for use on our development server.

My concerns:

• I'm using VS2015 + NodeJS Tools for my project development
  ** Personal preference here for IDE, since all my other work projects are VS, and trying to keep it simple for the next guy
  ** Visual Studio can launch a NodeJS application, in that I tell it what JS file to launch in the project Properties. I could probably pass in the node_modules/sourcejs path, but then if I'm doing anything else in script (retrieve CSS resources from TFS server) that needs to be done upon startup, it won't be processed.
• Heroku isn't on premise.
  ** Doesn't support .NET yet (one of the sites that would need to share the server)

iisnode seems to boil down to a node script.js type call, not a npm call. Once again, I could probably pass in the node_modules/sourcejs, but then anything pre-startup stuff I need can't be run.

[robhrt7]

Thanks for the explanation, now I get what you are trying to achieve. It's looks like a valid reasoning, and I would be happy to make SourceJS more compatible with different IDE's and cloud hosting.

My point here is about checking how to make the solution simpler, with less potential code to maintain. Therefore few more questions:

• Does VS allows to run npm scripts, instead of direct node script.js definition? If yes, npm scripts allow combining different pre/post actions, which you can use for bootstrapping your application
• Does iisnode allow executing other scripts before the actual application start? Usually services like that allow defining custom starting flows, where you can

node bootstrap-the-application.js
node ./node_modules/sourcejs/app.js

What if the start function was expanded to take in an options objects that could act as another way to configure the SourceJS server (like the command-line arguments)?

That's a good idea, and if we would go for exporting a set of programmable functions from SourceJS, we'll definitely need to have it.

[Alanoll]

My point here is about checking how to make the solution simpler, with less potential code to maintain.
I can definitely get on board with that.

From the nodejstools docs here, looks like it's NPM integration is from a package management perspective, not from a project launch/running perspective.
Their pre/post looks to be using grunt tasks, but from a project build perspective, where as I'm trying to achieve a more runtime update.

iisnode use the following to map the IIS handlers

<configuration>
<system.webServer>
<handlers>
<add name="iisnode" path="hello.js" verb="*" modules="iisnode" />
</handlers>    
</system.webServer>
</configuration>

Browsing the source code, it appears to just take the path and use it as the node command line argument.

That's a good idea, and if we would go for exporting a set of programmable functions from SourceJS, we'll definitely need to have it.

I don't know what the project roadmap looks like, but the no-opt path seems like it would be minimal (not affect current configuration setups), and the opt path could be pushed to 0.7 since it might need a little retooling of the commander to keep compatibility.

[robhrt7]

Alright, looks like there's no other options (at least yet) rather then expose programmable API from SourceJS main file. Let's proceed with PR then.

[robhrt7]

PR merged #241