-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use "engines" in package.json to specify Node and NPM versions #25
Comments
This would definitely be nice to have and fairly easy to implement, but we would lose the possibility to scale an application across multiple gears. As far as we noticed, OpenShift sets up the additional gears prior to syncing the package contents, and you'd end up running different Node.js versions on your gears (see here the issue that was fixed a few days ago). And since this is one of the few Node.js custom cartridges that permit scaling, I'd really hate to drop that feature. I am, of course, open to ideas / PRs, provided someone can come up with a solution covering both issues... |
Going to close this as 'wontfix' for now, since there's no way of implementing this while keeping scalability feature. |
I'm using this #!/bin/bash
#NODE_VERSION_URL
TARGET_NODE_VERSION=$(node -e "var p = require('$OPENSHIFT_REPO_DIR/package.json')||{engines:{}}; console.log(encodeURI(p.engines.node||''));")
echo "https://semver.io/node/resolve/$TARGET_NODE_VERSION" > ${HOME}.env/user_vars/NODE_VERSION_URL
#NPM_VERSION_URL
TARGET_VERSION=$(node -e "var p = require('$OPENSHIFT_REPO_DIR/package.json')||{engines:{}}; console.log(encodeURI(p.engines.npm||''));")
echo "https://semver.io/npm/resolve/$TARGET_VERSION" > ${HOME}.env/user_vars/NPM_VERSION_URL You can add it to your FAQ for those who need it... |
@Spown - That's an interesting idea. Does it work correctly on scalable deployments too? |
I don't know, probably? I guess if so, it would just run the build process for every scale instance independently since the instances are created on the separate gears, with their own env vars, but in the end the whole cluster will end up with the same versions. This example just automates an existent functionality you implemented yourself (the definition of the target version through env vars) so why not? What I meant was that you could add that example to the README as the solution for those who need it, while disclaiming any support for scalable apps. |
Like https://devcenter.heroku.com/articles/nodejs-support#specifying-a-node-js-version
The text was updated successfully, but these errors were encountered: