Still a -1, cordova (and all it's projects) should use the globally installed version of node.
If someone needs multiple versions of node the should probably use nvm [1] to manage it. IMHO this is a user problem and not something we should magically solve via bundled copies of node or hardcoded paths to specific versions of node. I agree we should have a version of node we support, it just needs to be consistent and common across all of our tools and require the user to have that version range in their path. [1] - https://github.com/creationix/nvm On Wed, Jun 19, 2013 at 3:57 PM, Bryan Higgins <br...@bryanhiggins.net>wrote: > For 3.0 will there still be a ZIP file released by Apache? Will the > instructions be download the latest version of node then run "npm install > -g <path to cordova-cli>"? > > My assumption was the individual project templates will continue to work > independently of CLI. > > Also, keep in mind that CLI invokes BB via shell scripts which in turn call > node. So for environments where people need different versions of node > installed, invoking CLI with an alternate node version will cause BB to be > invoked via the globally installed version. Perhaps that is an edge case, > but it's still something that needs to be supported by allowing them to > configure node path for BB. > > > On Wed, Jun 19, 2013 at 3:30 PM, Gord Tanner <gtan...@gmail.com> wrote: > > > I would expect they would have a supported node version when they type: > > > > "npm install cordova" > > > > which would do any version checks in the package.json [1] for supported > > node versions > > > > [1] - > > > > > https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=package.json;hb=HEAD > > > > > > On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins <br...@bryanhiggins.net > > >wrote: > > > > > So for Cordova 3.0 in general, users will be required to pre-install a > > > minimum version of node globally? > > > > > > We have had issues where upgrading node breaks stuff. I'd like to avoid > > > that and give users flexibility with their own system configuration. > > > > > > > > > On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner <gtan...@gmail.com> > wrote: > > > > > > > -1 > > > > > > > > I would rather we just use the system version of node which would be > > the > > > > same version as the CLI. I can't think of any reason a specific > > platform > > > > (aka BlackBerry) would need a special version of a common dependency. > > > > > > > > Also I don't think you can bundle binaries in an apache release. > > > > > > > > > > > > On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins < > > bhigg...@blackberry.com > > > > >wrote: > > > > > > > > > I'd like to reopen the topic of bundling node js into the > blackberry > > > > > platform. > > > > > > > > > > I have personally gotten feedback from users of errors which were > > > caused > > > > by > > > > > node version inconsistencies. We have since updated the check_req > > > script > > > > to > > > > > test for the minimum version of node we require, but that is not an > > > ideal > > > > > solution since users may need a different node version installed > > > globally > > > > > for other software. > > > > > > > > > > At a minimum, I'd like to give users the option to point to an > > > alternate > > > > > version of node. I have logged a JIRA issue for that. [1] > > > > > > > > > > What I'd prefer to do, is bundle the node binaries into the > > > distribution. > > > > > That would completely eliminate the dependency. Users would only > need > > > to > > > > > worry about setting up the native SDK. > > > > > > > > > > We already do this in the WebWorks SDK [2] > > > > > > > > > > I'm interested how the community feels about this. Are there any > > > > licensing > > > > > concerns in Apache hosting binaries without source? > > > > > > > > > > [1] https://issues.apache.org/jira/browse/CB-3798 > > > > > [2] > > > > > > > > > > > > > > > > > > > > https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node > > > > > > > > > > > > > > >
