> That is until I hit some packages that just *must* use a different (usually
> older) version of NodeJS than the one which I'm using.
In many cases, the package author just needs a nudge to get the
compatibility spec updated. That said, note that the newest versions
of npm treat an engine mismatch as a warning rather than an error, so
you may be able to ignore it, assuming the package actually works.
If you've tried that, and it's not happening (and you need to use an
old version of npm for some reason), it's possible that the package is
unmaintained or obsolete. In that case, you don't want to be using it
anyway.
If the package really is tied to a specific version of Node, that
could be because it's no longer needed in later versions, or it's
something that will take work to make compatible with newer versions
of Node. In this case, you're either stuck, or in for some additional
work, if you want to take it on yourself.
That said, if you feel you really need to build a check into your app,
you can do that very simply, unless I'm missing what you're trying to
do:
if (!require('semver').satisfies(process.version, MY_VER_RANGE)) {
console.error("Incompatible Node.js version");
process.exit(1);
}
--
Martin Cooper
On Sun, Oct 21, 2012 at 12:16 PM, ack <[email protected]> wrote:
> First off, I'm new to Node.js and npm, but I like it quite a lot already.
>
> I installed and tinkered with quite a few packages and tools, and I must
> say, I'm quite impressed with what npm can pull off in terms of package
> management.
> Local package versions per project, user-global packages by doing `npm set
> prefix $HOME/.local/` and then doing `npm install <package> -g`, system
> global installs with `sudo npm install <package> -g`, all really nice and
> dandy.
> No mucking about with Python's `virtualenv`, renaming script host
> executables, patching paths in scripts, none of that stuff.
>
> That is until I hit some packages that just *must* use a different (usually
> older) version of NodeJS than the one which I'm using.
> 'n', 'nvm', 'nave' all come to assist, but to me they just seem to introduce
> YAVE (Yet Another VirtualEnv), with all the troubles (activating,
> deactivating, keeping track of which shell you're in, etc.)
>
> I'm wondering if the following scheme could help out in all this
>
> Have an app.js check the version of Node.js it is running in, and have
> itself restarted using the correct version if mismatch, or bomb out if no
> match at all:
>
> --[app.js]--
> // Yes, I know that the 'node' package was used for installing Node.js
> itself
> // but it's deprecated now, anyway.
> require("node").version(">=0.6, <0.8"); // Yes, ignore the return value, we
> want the side-effects :-)
>
> // Do some cool stuff
> --[end of app.js]--
>
> This would introduce a Perl-like syntax for version requirement.
> It would be even better if node itself or a wrapper could read version info
> straight from the app's package.json, then the check could be done
> implicitly on startup.
>
> I'm not yet really clear yet on how to implement the "node" package, but as
> I see it, it could just export the function 'version', which checks its only
> argument against the running node version, and if it doesn't match, spawns
> the right version of node, passing it the original app script name and
> commandline parameters. The parent node process can then just exit.
> Maybe even better is to pass the required node version back to a node
> wrapper script, and have that exec() the right node version with the
> original app.js.
> An interesting bonus would be that scripts will not accidentally be executed
> using Windows Script Host or any other non-Node.js script hosts, as long as
> they don't have a 'node' package or script in their search path.
>
> Any ideas on whether my idea is feasible at all? Anyone interested in
> (helping me with) implementing this?
>
> Kind regards, Alain
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en