grunt-cli | Grunt 's command line interface | DevOps library

Node.js 4.4.4 is absolutely ancient.

It doesn't even show up on this page of releases, which says in part:

After six months, odd-numbered releases (9, 11, etc.) become unsupported, and even-numbered releases (10, 12, etc.) move to Active LTS status and are ready for general use. LTS release status is "long-term support", which typically guarantees that critical bugs will be fixed for a total of 30 months.

Version 4.4 is well beyond its maintenance window, and I strongly urge you to upgrade this project.

Having said that, there's a good chance you can get Heroku to run Node.js 10 to match your local version. Heroku only officially supports the current and active LTS releases, but it doesn't prevent you from using older releases:

Since Heroku is based on a standard Ubuntu Linux stack, you can run most Node versions (>= 0.10.0) on the platform. However, the testing and support focus of the buildpack will be oriented around active LTS and Stable releases.

Update the engines section in your package.json:

Try to add grunt-cli to your PATH after you run npm install -g grunt-cli:

In one of your .npmrc files, you probably have prefix=/Users/trott/.npm-packages. If so, leave it and create the directory with mkdir ~/.npm-packages. Or set it to a different directory. Or remove the entry entirely.

The places to look for the .npmrc file that may be causing this to happen:

• per-project config file (/path/to/my/project/.npmrc)
• per-user config file (~/.npmrc)
• global config file ($PREFIX/etc/npmrc)
• npm builtin config file (/path/to/npm/npmrc)

The problem was the distro. Since I was on debian 10 on my container I did a new container on debian 9 and it worked.

Simply install grunt and grunt-cli locally !

Node.js doesn't get bundled with the source code of apps. The package.json might have a section called "engines" in which it will state what version you should be using.

If the root package.json doesn't have the "engines" section, then it may be posable that the some of the dependencies do say which version they require to be used. It would be kind of annoying going through each one to check, so a good way would be just to download a version of Node and run npm install. If everything works, then you know that the Node version the app was created in is most likely older (its a bit tedious, I know).

Another thing you could look for (but might not be to helpful) would be to check when the files of the source code were created (especially the package.json file), and find the Node version that was released around that time. This wont be as accurate as the first method but it will give you a working version of Node.

When it comes down to it though, its probably always best to use the most up to date version (or the most recent LTS version) as they come with all the latest security patches and improvements.

Make sure servicePort defined in the ingress matches with the port defined in bobtest-1 service and the service's TargetPort matches with the containerPort defined in the pod spec.

Another thing to note here is that there is probably nothing being served at path /bob. But nginx by default will send traffic to the /bob as defined in the path. To avoid that you can add below annotation in the ingress resource.

Cordova depends on "init-package-json" which in turn depends on "read-package-json: 1 || 2".

Now there's been an update to "read-package-json" some months ago which introduces a new dependency to "npm-normalize-package-bin". This package makes use of a syntax construct that's apparently supported not before node 6.0.0.

So, if updating node is not an option (which is recommended, since node 5 - 8 is end-of-life), you may install this (also rather outdated) cordova locally (inside the project folder) and overwrite the read-package-json dependency there by npm i read-package-json@2.0.13.

Edit: Call cordova via npx: npx cordova -v