I upgraded "node" to "node 14", and ran an "npm install", but the install failed because of an error while attempting to compile "kexec" (a.k.a. "node-kexec"); which is required by "WebPack".
Error messages include:
npm ERR! path /Users/my_self/my_project/node_modules/kexec
...
npm ERR! In file included from ../src/kexec.cc:14:
npm ERR! In file included from ../../nan/nan.h:2884:
...etc...
npm ERR! ../src/kexec.cc:19:11: error: no member named 'Handle' in namespace 'v8'
...etc...
npm ERR! 1 warning and 9 errors generated.
npm ERR! make: *** [Release/obj.target/kexec/src/kexec.o] Error 1
npm ERR! gyp ERR! build error
...etc...
npm ERR! gyp ERR! not ok
This issue only shows up for projects that have a dependency upon "kexec". The actual purpose of "kexec" is to launch programs by passing a request to the OS, either directly or through a shell like "bash".
As it happens, WebPack depends upon "kexec". So to get WebPack working with "node" versions 12, 13, 14, etc, "kexec" has to compile.
This problem has already been documented and fixed on GitHub. In fact, there is a radically new version of "kexec" available, waiting for a "pull" to the master branch. The problem is that the "pull" has languished.
How can use the fixed version of "kexec" within my "npm install" to rebuild the "node_modules" directory as required by "WebPack"?
I was able to successfully get a revised version of "kexec" (a.k.a. "node-kexec") to compile via "npm install" despite an upgrade to "node" (node 14), the result being well built "node_modules" fulfilling requirements for "WebPack".
If using "npm" version "8.3.0" or higher, try using "overrides". See "Candidate Method 3", below. In my case, I didn't explore using "overrides" becasue I am using a version of "npm" that does not have the capability. Instead, I did some trickery.
The required version of "kexec" is 3.0.0, but that is old code which breaks when "node" is upgraded to or beyond "node" version 12.
An all new "kexec" 4.0.0 has been written. The re-write was available back in Oct 2020, but as of Jan 26, 2022, the revision is still languishing. The new code is awaiting a "pull" into the "master" branch. This v4.0.0 fixes the problem, except for the fact that "npm" can't find it.
"WebPack" requirements call for "kexec" v3.0.0; which is the broken version. It can't find v4.0.0 because it's not in the master branch. The obvious solution would be to convince "npm" to look elsewhere for "kexec". Some transparent override methods are described here. These methods involve modifying the "package.json" file; (hence, transparency). Later in this answer, I also describe a non-transparent method; this "trickery" is what worked for me.
Method 1 with package.json: Use "yarn" and "resolutions"
As per "tamlyn", Jul 15, 2020, "if you're using Yarn...[add] the following to your package.json:
"resolutions": {
"kexec": "meteor/node-kexec#update-for-node-12"
}
But this does not fit my situation, since I am using "npm", and not "yarn".
Method 2 with package.json: Use "npm" and "npm-force-resolutions"
There is a module "npm-force-resolutions" that attempts to make the above mentioned "resolutions" idea work with "npm". However, the word is that it works only with older versions of "npm".
Method 3 with package.json: Use "npm" and "overrides"
For "npm" version 8.3.0, there is a built in feature called "overrides" that is supposed to be the equivalent of "resolutions". Here is the documentation for it:
https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides
Presumably, the syntax for use would be like that shown above for "yarn", but with the word "overrrides" replacing "resolutions". If you are using a version of "npm" that is v8.3.0 or higher, you should try this. I did not explore this.
Non-Transparent Method
If possible, start by upgrading to the latest version of "npm".
$ sudo npm install -g npm#latest
And then check the "npm" and "node" versions. In my case, because several machines need to be coordinated, I did not have the absolute latest. Here is what I was working with:
$ npm --version
v7.12.0
$ node --version
v14.18.3
Having sufficiently upgraded "npm", you are ready to actually start fixing the "kexec" problem. If you have "npm" version 8.3.0 or more, try "Method 3", mentioned above. If that doesn't work, proceed as follows.
In this documentation, I will use the word "my_project_dir" to represent the directory in which you are trying to create your "node_modules" sub-directory. Start by going to that location.
$ cd my_project_dir
Move aside the existing "node_modules" directory (if any exists).
$ mv node_modules node-modules-old
You should now attempt a fresh install. Of course, this install will look at "package.json" or "package-lock.json", and know what is needed. However, presuming your development environment requires "kexec", and because the old "kexec" has trouble compiling within the new "node" environment, the install hits a wall; as shown here
$ npm install
...
make: *** [Release/obj.target/kexec/src/kexec.o] Error 1
... etc,
... etc, etc, more "build error" messages
In my case, I use "WebPack", which has a dependency on "kexec v3.0.0", which breaks when used with upgraded "node".
The totally new version of "kexec", which is the creation of a group of developers at "Meteor", is available on "github", directly through one of the developers, who goes by the user-name "StorytellerCZ". (See also list of URLs at end of this doc).
Use "git" to download the updated code. Actually, what I did was a "git clone" of the entire "node-kexec" module repository, as presented by "StorytellerCZ". This download has more than is needed, but that's ok.
$ pwd
/home/myself/my_project_dir
A "node_modules" sub-directory exists; it was created by the attempted "npm install". Descend into the sub-directory.
$ cd node_modules
$ git clone https://github.com/StorytellerCZ/node-kexec.git
This creates a sub-directory named "node-kexec"; which is a "git" repository. Note that the desired directory name is actually "kexec", but, for now, having two different names ("kexec" versus "node-kexec") will actually keeps things cleaner.
The next step depends upon whether a "kexec" directory already exists. Check for it.
$ ls -ld kexec
drwxr-xr-x 16 myself staff 512 Apr 30 2021 kexec
The "kexec" subdiretory might not exist; this depends upon what was left over from the failed "install"; (the "install" that got you looking for a fix in the first place). On my Mac OS X (BSD) system with "npm --version" of "7.12.0", the "kexec" remnant was preserved. On an AWS Linux system with "npm --version" of "6.14.15", the "kexec" directory was destroyed at every failed "npm install".
If the "kexec" directory exists, you just need to cherry-pick one file from the git clone. First move the old file asside; the following command moves the old file to a new name where-in "-2016" is a reminder of the year of the most recent "pull" of the source code for "kexec".
$ mv kexec/src/kexec.cc kexec/src/kexec-2016.cc
Now replace that with the desired version
$ cp -p node-kexec/src/kexec.cc kexec/src
And remove the clone, so that it doesn't cause problems at some later date.
$ rm -rf node-kexec
On the other hand, if "kexec" is not present as a subdirectory, then you must convert the "node-kexec" repository into a directory that is named "kexec".
$ mv node-kexec kexec
However, you probably need to do one more thing; a bit of subterfuge. The package dependencies for your project might include a requirement for exactly version "3.0.0" of "kexec"; this is the case for my project, which I assume is because of some dependancy of "WebPack". The "kexec" from "StorytellerCZ" is labeled as version "4.0.0"; (and indeed, it is an entirely new body of code). This is problematic, because, on some systems, "npm" will actually delete the subdirectory you just created, and replace it with the same old, bad "3.0.0" code. Therefore, some subterfuge is necessary.
To trick the "npm" system into accepting the new directory, edit the "package.json" file, and modify the value of the "version" parameter to "3.0.0". Yes, this really stinks, but it solves the immediate problem. (The real solution will be for the "4.0.0" changes to finally get integrated into the "master" branch.) The following steps make the change, cautiously.
Descend into pre-existing "kexec" directory, under "node_modules".
$ cd kexec
Make a copy of the file you are about to change. This leaves a clue for you, in the future, when you are wondering how the version number got the way it is.
$ cp -p package.json package.json-original
Edit the "package.json" file. For example, if your editor is "vim", you could invoke the editor like this:
$ vim package.json
Change the "version" value; make it "3.0.0". When that's done, save the edit and quit the editor.
Ascend out of the "kexec" sub-directory, back to "node_modules".
$ cd ..
So, at this point you have prepared a "kexec" module that should compile. You did it one of two ways: either (1) you had a pre-existing "kexec" directory and you simply copied over the updated "kexec.cc" file, or (2) you renamed "node-kexec" to "kexec" and you fiddled with the "version" number.
To re-try your install, first ascend out of the "node_modules" sub-directory, back to your project directory.
$ cd ..
Prove to yourself that this is the right place.
$ pwd
/home/myself/my-project-dir
Do the install.
$ npm install
The "kexec" error should be gone.
If you are still getting errors, check whether the very first line of warning message says the following:
npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion#1, but package-lock.json was generated for lockfileVersion#2. I'll try to do my best with it!
This warning should go away when you upgrade the "npm" version to 7.12.0 or better. Do so!
If "npm" protests about the presence of "git" information, that should go away once you upgrade the "npm" version to 7.12.0 or better. If the warning persists, then you can just get rid of the "git" info, as follows.
Descend into the repository dir
$ cd kexec # formerly named "node-kexec"
Confirm, just for fun, that the "git" structure is actually here. Note that "ls *" won't show hidden files, hence use this command:
$ ls -a | grep git
.git
.gitignore
Strip out the git repository information.
$ rm -rf .git
$ rm .gitignore
Ascend out of the "kexec" sub-directory, back to "node_modules".
$ cd ..
$ pwd
/home/myself/my-project-dir/node_modules
Retry the "npm install".
Appendix I
Here are some URLs to relevant github archives:
[https://github.com/jprichardson/node-kexec/issues/36][1]
[https://github.com/StorytellerCZ/node-kexec.git][1]
[https://github.com/meteor/node-kexec/tree/update-for-node-12][1]
Appendix II
On OS-X, the intermediate binary object file created during the build is:
node_modules/kexec/build/Release/obj.target/kexec/src/kexec.o
On OS-X, the executable appears to be:
node_modules/kexec/build/Release/kexec.node
On AWS Linux, I did not find either of those. I didn't bother to
seek an explanation, since WebPack had become functional, and
therefore my goal was achieved.
I'm getting the following error when I npm start the application at https://github.com/juanmendes/vmware-cloud-director-ui-components for the branch named ryan-a11y-merge-to-master. If I run the master branch, I get no errors.
ERROR in The target entry-point "#vcd/ui-components" has missing dependencies:
- #angular/core
- #clr/angular
- #angular/common
- rxjs/internal-compatibility
- #angular/platform-browser
- #angular/core/testing
- #angular/forms
- #angular/router
- rxjs
- rxjs/operators
- #clr/angular/data/datagrid/interfaces/filter.interface
I also see the following error messages before this final error:
Warning: Entry point '#vmw/ng-live-docs' contains deep imports into '/Users/jmendes/git/github/juan-core-ui/node_modules/prismjs/components/prism-scss', '/Users/jmendes/git/github/juan-core-ui/node_modules/prismjs/components/prism-typescript'. This is probably not a problem, but may cause the compilation of entry points to be out of order.
Warning: Entry point '#vmw/plain-js-live-docs' contains deep imports into '/Users/jmendes/git/github/juan-core-ui/node_modules/lit-html/directives/unsafe-html'. This is probably not a problem, but may cause the compilation of entry points to be out of order.
Warning: Entry point '#vcd/ui-components' contains deep imports into '/Users/jmendes/git/github/juan-core-ui/node_modules/#clr/angular/data/datagrid/interfaces/filter.interface'. This is probably not a problem, but may cause the compilation of entry points to be out of order.
If I ask colleagues to clone that repo and run it:
git clone https://github.com/juanmendes/vmware-cloud-director-ui-components.git
cd vmware-cloud-director-ui-components;
git checkout ryan-a11y-merge-to-master;
npm ci;
npm start;
They have been able to run the application (and also get the warnings) without a problem but I get the error above and get the following message at localhost:4200: Cannot GET /
What I have tried
Deleted node_modules and the dist folder
npm cache clean
npm unlink #angular/core (both steps in the package folder and the project including it)
npm unlink #vcd/ui-components (both steps)
Completely removing node, npm, nmv and reinstalling them
Workaround
If I disable Ivy compilation, then it complains because one of the packages it uses (#vmw/live-docs), doesn't declare entryComponents for some dynamically created components (since they are not needed in Ivy compilation).
To get past that problem, I modified the code in #vmw/live-docs to have entryComponents and re-built it, copying its dist folder to node_modules in my current application. This allows me to run the app in non Ivy mode, which is not what I want
What else can I try ?
I am out of things to try, any suggestions are welcome.
This was happening because I somehow had a ~/node_modules/#vcd/ui-components with stale references.
It seems that node module resolution was going up the tree and trying to use that version instead of the one I had configured in ~/github/vmware-cloud-director-ui-components/tsconfig.json
"compilerOptions": {
"paths": {
"#vcd/ui-components": [
"../../dist/components"
]
}
},
Deleting that node_modules folder fixed my problem
We are trying to get a simple noflo example running inside a browser as described the noflojs.org/documentation/fbp/ [Language for Flow-Based Programming]
We tried to refer to some examples available on GitHub
github.com/noflo/noflo-browser-app
github.com/noflo/noflo-websocket
github.com/bergie/flowcopter
We tried npm install; grunt build. We get the below error and are not able to proceed beyond this:
Running "noflo_browser:build" (noflo_browser) task install
noflo/noflo#master Warning: dns lookup failed Use --force to
continue.
Any idea what are we missing ?
At the time of the question the build setup for the projects mentioned was still based on Component.js which had become unmaintained.
Nowadays we're using NPM for installing dependencies and WebPack for browser builds.
Suggested fix would be to fetch the latest versions of these repos, do npm install and build again. This will bring the build up to spec.
If you're using the old build setup in your own projects, this PR is a handy example on what to change to go from Component.js to WebPack.
I'm adapting an existing project to use Grunt, Assemble and other workflow tools. I have the workflow working on one machine, but when I try to run the Gruntfile on a different system I get an error:
[/home/ian/workspace/myproject] (master)
ian#ian-desktop $ grunt assemble
Running "assemble:pages" (assemble) task
Warning: Cannot find module '/home/ian/workspace/myproject/node_modules/
grunt-assemble/node_modules/assemble/node_modules/handlebars-helpers/
lib/helpers/home/ian/workspace/myproject/node_modules/grunt-assemble/
node_modules/assemble/node_modules/handlebars-helpers/lib/helpers/code.js'
Use --force to continue.
Aborted due to warnings.
The path that Grunt is trying to load is completely messed up (note the re-occurrence of the cwd about halfway through), but the filename it's looking for - code.js - is installed locally (by npm -i):
[/home/ian/workspace/myproject] (master)
ian#ian-desktop $ find . -name code.js
./node_modules/grunt-assemble/node_modules/assemble/node_modules/
handlebars-helpers/node_modules/remarkable/lib/rules_block/code.js
./node_modules/grunt-assemble/node_modules/assemble/node_modules/
handlebars-helpers/test/code.js
./node_modules/grunt-assemble/node_modules/assemble/node_modules/
handlebars-helpers/lib/helpers/code.js
./node_modules/grunt-mocha/node_modules/mocha/node_modules/jade/
lib/nodes/code.js
Both the systems I'm working on are Ubuntu 14.10, so shouldn't differ in any material way. Node -v gives v0.10.33, npm -v gives 2.1.5. I've tried:
checking out a fresh copy of the entire project from git
clearing all Bash environment vars before running Grunt
I'm having a hard time figuring out what's at the root of the different behaviour of the same code on two similar machines. Other tasks in my Gruntfile seem to be working fine, it's just the assemble task that's broken. Suggestions of where to look, or debug techniques to try, would be very welcome!
I have been using Yeoman to start building with web apps and such for maybe the last month. And I have been running into some issues and have been able to resolve most of them. However, now I am stuck.
I'm running MAC OS 10.6.8
I have reinstalled Yeoman and Node fixed my paths for (what I know) as global.
Running grunt in my app.
Forces me to run as sudo. (I think this is because this OS has password protected permissions for apps and programs to install/modify files.
** If I run grunt -f
Warning: Unable to write "dist/scripts/vendor/modernizr.js" file (Error code: EACCES). This error happens with most of the main tasks in grunt.
Running sudo grunt
grunt runs through the tasks just fine until the real issue I cannot locate an answer.
Running "modernizr" task
Enabled Extras
shiv
load
cssclasses
Looking for Modernizr references
in dist/styles/main.css
svg
input
Downloading source files
cache modernizr.load.1.5.4.js
And grunt will not finish this download of source files. When I ran grunt using force it would complete the download. I am looking for a solution for the 2nd list item. Any assistance would be helpful.
Found out that there some glitch in the npm grunt-modernizr.
I used this code:
npm remove grunt-moderizr && npm install --save-dev grunt-modernizr
found here: https://github.com/Modernizr/grunt-modernizr/issues/48