Can anyone tell us how to change the node version used to run a zapier app to node 6.10.2 or later?
Zapier cli docs state that All Zapier CLI apps are run using Node.js v6.10.2.. Our app is built using the cli.
Elsewhere in Zapier docs it states that The environment is vanilla node.js v4.3.2 which runs JavaScript.
We already did z.console.log('node version', process.version); from within the Zapier app so that we can see the node version where it is run. We retrieved this using zapier logs. The version logged is 4.3.2.
Previously our package.json contained:
json
"engines": {
"node": ">=4.3.2",
"npm": ">=2.0.0"
}
We have updated this to:
json
"engines": {
"node": "6.10.2",
"npm": ">=2.0.0"
}
The same applies for the travis.yml which was previously 4.3.2 but is now:
yml
node_js:
- "6.10.2"
Thanks ; )
SOLUTION
As noted in the accepted answer below, zapier cli apps are currently run with node 6.10.x. We changed the node version in our package.json under the engine key to be 6.10.2, but this alone did not change the node version it was run with. The node version was updated when we changed the zapier-platform-core dependency to be 4.3.1 (it was previously 1.x), and logging process.version now shows the version as 6.10.3.
The zapier App does not run in your machine. It only gets built and validated via 'zapier validate' and each time you do 'zapier push'. You only run the optional tests in your machine. So, when CLI checks your app, it runs node 6.10.2 and this is why you need this in your machine. Once your app is uploaded, you do not really care where it runs, but they say it is node 4.3.2
David here, from the Zapier Platform team. Just wanted to clear up some confusion here.
We've got 2 separate platforms, both of which are run in Lambda. Currently, they run different versions of Node.js. The Web Builder runs 4.3.2 and the CLI runs 6.10.2. You can read more about the differences here.
To answer your question, there's no mechanism to have a Web Builder app run Node 6 right now, but we'll need to move them all at some point.
I'll see what I can do about making that distinction more clear in the docs. Sorry for the confusion!
Related
It seems that the only way to upgrade the version of Node used by Meteor is to upgrade Meteor, according to the following:
How to change or upgrade the version of Node.js in Meteor
Update Node version for Meteor app deployed to Heroku
You can run your production bundle with other node versions, it is just not guaranteed that it will work. In practice though, I've done this many times and have never run into any issues (always using newer versions of node).
In development meteor uses the node binary in
~/.meteor/packages/meteor-tool/METEOR_VERSION/mt-os.linux.x86_64/dev_bundle/bin/
where METEOR_VERSION is the version of meteor your project is using, e.g., 1.12.1. So you could go there and replace that binary with a symlink to another node executable if you want to and it will probably work for most newer versions of node.
In development: difficult. Your Meteor project uses its own embedded Node version, and trying to change it might also require reconfiguring the dev mode build and tooling...
In production: if you have control of the server environment, then yes, you can try another Node version, at your own risks regarding compatibility with Meteor code. However the latter checks that your Node major version is at least the one required by Meteor.
In Heroku: if you use the Meteor buildpack horse, then no. The buildpack configures your Heroku environment as required by the Meteor version of your project, including the Node version.
I am currently getting my feet wet using Express. To start out, I used express-generator to scaffold a simple app.
While examining the project, I noticed that the npm start command is mapped to a binary (bin/www). Upon further inspection I noticed that this file actually contains code to be executed in Node, hence the #!/usr/bin/env node pragma. For anyone having a deeper understanding of Express/Node the answer may be obvious, but still I am wondering: Why didn't they simply use a .js file to bootstrap the framework. That file could then be run using node www.js, I imagine.
There are probably a few reasons why the script was made an executable
npm scripts can be mapped to execute local JS files in the project or executables on the system.
By mapping npm start to bin/www it is effectively the same as running ./bin/www on the command line with the important distinction that by running it via a npm start, it will also work cross platform (e.g. on systems that ignore the hashbang statement, like Windows), otherwise you would need to run it as node bin/www on those systems.
There's a binary ready to add to startup scripts.
I am trying to learn Electron (Atom-Shell) but I am finding it pretty tough to find documentation for it...
I am simply trying to figure out how to create a link with in index.html, and have it open a terminal window or run some sort of program.
I learn languages by learning specific tasks as I need them in a program, so that is why I am asking so then I can utilize the technique used in other ways in my programs.
Thank you for helping.
Well, essentially Electron is just a customised version of a Chromium browser that comes packaged with Nodejs and some really cool packages that basically allow you to run the custom browser as if it was a native platform application. Because of that creating an Electron app is very similar to creating a web-app that has a Nodejs back-end.
So to get started with a simple "Hello World!" app, you can just run the following npm...
npm install electron-prebuilt --save-dev
Once the npm is installed you'll need three files to run an Electron app.
A package.json file
A javascript file (default is main.js)
An html file (default is index.html)
See this GitHub repo for a quick copy/paste version of each and more detailed instructions: https://github.com/mafintosh/electron-prebuilt
after that you're ready to simply run your app...
$ electron .
Finally, one way to open a terminal window would be to use an onclick attribute in your html to trigger a child_process, found here, in a function.
That's it! You should be able to edit your html and javascript files as you would for any web-app, and take advantage of the added features that Electron provides.
I'd also check out these resources for more info:
A Quick Start intro to how Electron works -- https://github.com/atom/electron/blob/master/docs/tutorial/quick-start.md
The Atom discussion forum (Because Atom was built with Electron, and is made to be hackable, the community is quite active) -- https://discuss.atom.io/c/electron
A cool repo to keep up with the latest info. It includes links for apps that currently use Electron, tutorials, videos, and more --
https://github.com/sindresorhus/awesome-electron
I hope that helps!
Using these instructions I was able to easily install node.js on RPi. The problem was that since build v0.10.29 node.js has not included a build for the RPi. The current build is v0.10.31.
Does anyone know why node.js stopped including the RPi build with their new versions?
Is there a way to get the latest RPi build from another source?
This is my first question on SO, so hopefully I haven't mucked it up too much.
I took a look at the google group Zlatko suggested. I found that Nathan Rajlich compiles the RPi builds, but has run into an issue since v0.10.29.
Currently, however, v0.10.29 and v0.10.30 are failing to compile on ARM out-of-the-box. Follow this issue for updates on that: https://github.com/joyent/node/issues/8062.
It seems there is some hacking around to deal with the errors cropping up. It is beyond me, which is why I liked the node.js build for the RPi in the first place. I will continue with the old node.js build and hope for a RPi build in the future.
Follow these instructions here:https://github.com/audstanley/Node-MongoDb-Pi
You'll get nodejs v5.3.0 and MongoDb on the pi view the read me on how to install. Only four lines of code you'll need to copy paste into your CLi, and you'll have nodejs and MongoDb up in about five hours. (Mongodb takes quite some time to compile).
Does anybody know if this issue of old node versions regarding using https://github.com/dockyard/es6_module_transpiler-rails on Heroku has been resolved.
https://gist.github.com/bcardarella/7384208
Copying the gist:
I have been working with Peter Wagenet from Tilde on getting support
for Ember Appkit on Heroku with a Rails app. First some background:
Ember Appkit will Transpile ES6 modules for use as AMDs. To that end I
wrote the es6_module_transpiler-rails gem which uses Node and Square's
es6-module-transpiler package. That package makes use of Esprima for
the parsing. There is an issue of a reserved keyword in older
JavaScript runtimes not being quoted properly:
https://code.google.com/p/esprima/issues/detail?id=469
On our local machines everything works OK and the transpiling does not
bomb out because our versions of Node are recent. However, when we
deploy to Heroku and Rails attempts to pre-compile its assets the
version of Node that Heroku uses is out of date. Based upon some
research it appears by default Heroku is using Node v0.4.7 which is
from April 2011. It is easy enough to force Heroku to use a more up to
date version of Node:
https://devcenter.heroku.com/articles/nodejs-support#versions however
it is currently unclear if this will run side-by-side with a Rails app
for pre-compilation. Furthermore, I do not think it is reasonable to
ask Rails developers to include Node configuration code for Heroku in
the apps.
I respectfully request that the default version of Node for Rails's
asset compilation get bumped up to a more recent version.
we support integration through node by using multi buildpack and by defining a package.json in your application. Here's the PR https://github.com/heroku/heroku-buildpack-ruby/pull/245
Make sure nodejs comes first in the .buildpacks file then you can get any version of Node you want.