Starting with AWS-Lambda and the Serverless Framework i am confused about node versions:
The AWS help site says that (on 21-March-2016)
AWS Lambda supports the following runtime versions:
Node.js: v0.10.36
So i did install Node.js v0.10.36 on my local machine. Installing the latest (v 0.4.2) serverless framework via
npm install serverless -g
it gives the following warning:
npm WARN engine serverless#0.4.2: wanted: {"node":">=4.0"} (current:
{"node":"0.10.36","npm":"1.4.28"})
I thought having the same version locally as on AWS might help having a consistent development environment... Am i wrong? What Node.js version should i run locally to get the most out of serverless?
The Serverless Framework requires Node.js v4.0 or higher. Any version of Node.js within the v4.x or v5.x lines should work.
You are correct that AWS Lambda currently only supports Node.js v0.10.36. The decision to build the Serverless Framework on Node.js v4.0 was done in anticipation that AWS Lamabda would eventually support Node.js v4.0 or higher.
When developing code for AWS Lambda, you should continue to only use features compatible with Node.js v0.10.36. If you make any contributions to the framework, you can use Node.js features available in v4.0+.
Another option is to use Babelify to transform your ES2015 code uploading to AWS Lambda. This allows you to develop in ES2015 without having to wait for AWS Lambda to officially support it. This can be done automatically each time you deploy with the Serverless Framework using the Optimizer Plugin.
Update: A new option now exists, the Serverless Babel Runtime. This goes one step beyond what Optimizer does, and uses Babel inside the runtime itself.
Update 2: AWS Lambda now supports Node.js v4.3.
If you are starting out with a brand new, fresh project I would highly avoid starting with node 0.10.x. That version is just receiving important security fixes at this point, and only for another five months (until October 2016).
The Node.js has adopted the common Long Term Support (LTS) pattern to keep releases timely and stable. Here is the current LTS plan for node.
I would highly recommend starting out with version 4 or 5, depending on your appetite for change and keeping your project up to date. You will be able to take advantage of numerous new features over the 0.10/0.12 releases as well as better prepare you for ES6.
Related
I have a Node 12 app and am trying to assess when i should migrate up to a newer version of Node. Even though it is no longer officialy suppported the app builds today on v12. I read in heroku's documentation (https://devcenter.heroku.com/articles/nodejs-support) that I can install "most node versions". That seems to explain why the app is still building, but then I also read that official buildpack support is given to active or LTS node versions.
Given the above, what is the implication for older apps? That it will build until a breaking change in the buildpack stops it from building? Is there a buildpack per node version which, if true, would mean that the build will work but without benefit of updates or bugfixes?
My goal is to develop a VS Code extension with speech recognition, ideally via google's API.
When attempting to import and use #google-cloud/speech, the following error is thrown at runtime:
Error: #grpc/grpc-js only works on Node ^8.13.0 || >=10.10.0
VS Code (as of 6/20/2019) is running electron 3.18 and node.js 10.2.0. Does this mean there is no way to work around this issue?
I'm following this tutorial: https://cloud.google.com/speech-to-text/docs/streaming-recognize
Sounds like it should work starting with the next release then. From the preliminary 1.36 release notes:
The Electron version that VS Code runs on has been updated and brings with it an update to Node.js from 10.2.0 to 10.11.0. All extensions will now run on this newer version of Node.js.
To make sure, you can try an Insider's build.
Generally speaking though, there's no way to control what Node version VSCode extension run on (see here), so I guess you got lucky here. :)
I got simple node.js code that works ok on my laptop. This testing nodejs application just selects a row from a Db2 database in IBM Cloud. However, when I integrated the code and deploy to IBM cloud, it complains "Error during initialization: { Error: Cannot find module 'connect:db2'( or ibm_db )".
I think that the environment in IBM Cloud does not have the ibm_db installed, My question is what are steps to install ibm_db to IBM Cloud to get the application (actually it is an action of a package in IBM Cloud) working?
The ibm_db package is part of several runtimes of IBM Cloud Functions. For Node.js with Db2 I recommend to use the Node 8 or Node 10 runtimes. You need to specify the version when you create the action.
The solution tutorial on how to build a database-driven Slack chatbot uses Cloud Functions to access Db2. The code is written in Node.js and available on GitHub with instructions on how to deploy it. See the link.
Meteor is typically behind in Node.js version because it is a framework that uses its own bundled version of Node.js, and its APIs and features are built to rely on that version of Node.js.
I'm sure that in many cases upgrading Node.js poses no problem.
As an example, Meteor 2.10 at time of writing ships with Node.js 14. But we're already on Node.js 19.
Is there a way to tell Meteor (f.e. with the meteor cli, or some meteor package) to use newer versions of Node.js (and npm)?
Meteor 1.4 now supports Node 4.4.7!
See release notes
To upgrade to Meteor 1.4:
Go to the root of your project's directory
meteor update
Meteor does not support NodeJS 4+ as of now. The discussion is available in https://github.com/meteor/meteor/issues/5124
The latest update to the thread on April 29 is:
Guys, relax. The difference between Node version 4, 5 and 6 are relatively minor, and so if Meteor can support one, it can and will support all others. Ben created PRs for every currently active and supported Node version, but the fundamental part of the work is about making Meteor work with any (recent, non-legacy) Node version, and from there basically everyone should be able to freely select whichever one fits their goals and intentions best (i.e. 4.x if you don't care for bleeding edge Node, 6.x if you do; 5.x is not going to stick around for very long as it's not an LTS version).
So come and check out and help with the PRs if you're interested and
you can, but if not, just rest assured this is being worked on and
prioritized appropriately and I'm pretty sure Ben (and/or others
working on this) will keep everyone posted on any meaningful progress.
I'm having trouble getting a nodejs app which relies on JSDom to work on Azure due to it depending on a native module - Contextify, I understand Azure does not provide compilation for native modules.
However according to Azure documentation
Since Windows Azure Cloud Services rely on the node_modules folder being deployed as part of the application, any native module included as part of the installed modules should work in a cloud service as long as it was installed and compiled on a Windows development system.
It all works fine on my dev box as it's compiled during npm install, what I don't understand is why it isn't working on Azure as I am providing the compiled version? If it works on my windows dev box the compilation is clearly successful. I deploy to azure form a local git repository so I'm wondering if the compiled files are being left out when I commit?
UPDATE: the latest Azure release (specifically, the Mobile Services backend) supports arbitrary NPM modules - See the section on Mobile Services: NPM Module Support
From the JSDom docs on the npm:
Unfortunately, doing this kind of magic requires C++. And in Node.js, using C++ from JavaScript means using "native modules." Native modules are compiled at installation time so that they work precisely for your machine; that is, you don't download a contextify binary from npm, but instead build one locally after downloading the source from npm.
https://npmjs.org/package/jsdom#contextify
Since your "native modules" don't have the same signature as whatever machine in azure's "native module" would be signed, it doesn't load.