I am trying to install modelling node module using npm. Here is the link https://www.npmjs.org/package/modelling
It keeps throwing me an error. No compatible version found: waterline#'balderdashy/waterline'
I have installed all the dependencies of modelling separately i.e. waterline, lodash, express, extend.
Still it throws me the same error. Anyone knows a work around for this?
Only thing I see, in package.json :
"waterline": "balderdashy/waterline"
Is this a correct semantic version? Try replace it with "*" (any versions) and see.
Hope it's help!
Maybe modelling is a peer dependency to openid-connect, if so It have to be bundled in node_modules folder of openid-connect. Give it a try and tell us.
Related
I'm pretty new with NodeJS and I'm trying to use a module called "updated-node-msmq" (from this repository) in my project but getting an error.
What I've done:
I opened a new folder for the project.
I used the command "$ npm install --save updated-node-msmq" and got some warnings (Screenshot attached).
When I try to use the module according to the README, and run my "test.js" file I got the following error here in the screenshot).
I am using version 14.16.0 of NodeJS and after trying to fix this myself I realized that probably the problem is that the module was built for older versions of NodeJS.
I understand that low version is not a recommended solution, but I have no clue how to update a module.
Help / guidance in solving the problem?
Thanks in advance everyone!
Why are you using updated-node-msmq? That package seems like a mess, and the errors you are getting is because the whole module is written with ES2015 but doesn't seem to have been transpiled to node.js compatible code before published to NPM.
I'd advise you to use a tried and tested module for MSMQ first and foremost.
EDIT: Seems like the author fucked up in the 0.2.0 version. You could use the 0.1.9 (by instead using npm install updated-node-msmq#0.1.9 but that one is 3 years old.
I keep getting this issue:
[snip of my issue][1]
I'm teaching myself node and am trying to make a CRUD RESTful application in my spare time. I'm working off this book:
https://leanpub.com/mean-machine.
For the past 3 days I've been stuck with this issue. It is specifically concerning the bcrypt-node.js . It's job is to hash passwords. Some things I have tried.
Downloaded python 3.5 as I got errors saying the runtime was needed to execute.
Setting python environment variable in PATH
npm uninstall and install.
Tried creating a new project, same issues cropped up.
npm clear cache
Since it is an old version of the bcrypt-node.js module changed the version in package.json from "0.0.3" to "0.0.5". I thought it could be a bug. Unlikely as that is.
I'm very new to node.js so I feel like I'm doing something silly that I just cannot see. Also I don't understand a lot of the information the command line is providing me. Thank you in advance.
EDIT 1:
Picture of my code.
Edit. (For future visitors) I needed to pay more attention to the various dependencies and a further understanding of JS in general to utitlise the power of Node.js, which is something I didn't do. Also recommended is a good understanding of Express.
A deeper understand of the npm is needed.
I found a fix through trial and error and some googling.
In case any one looks up this again in the future I entered:
npm install node-gyp -g && npm cache clean && rm -rf node_modules && npm installinto the command line and it appeared to fix the issue when I ran nodemon server.js
Fingers crossed it does not crop up again.
If someone would like to explain to me what exactly was the problem I had I would really appreciate it. I have a feeling a module or dependency wasn't installed correctly?
EDIT 1. Furthermore configure the PATH in your environment variables.
ie I created a path for python in the command line
PATH python = C:\Python27\python.exe & another PATH for MongoDB
i.e C:\Program Files\MongoDB\Server\3.2\bin
I'm pretty new to node.js and its package management system and its require. I'm having trouble with the following runtime error I'm getting after having installed a bunch of packages with npm install:
ERROR: Couldn't initialise framework "wdio-mocha-framework".
Error: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found
(required by <path>.../node_modules/fibers/bin/linux-ia32-v8-5.0/fibers.node)
at Error (native)
My understanding of the error is that the binary fibers.node was compiled with a newer libstdc++ than the one available at runtime.
It appears to me like the npm install did compile a fibers.node:
> fibers#1.0.13 install <path>.../node_modules/fibers
> node build.js || nodejs build.js
make[1]: Entering directory `<path>.../node_modules/fibers/build'
<snip some output, including warnings, here that I don't deem relevant>
Installed in `<path>.../node_modules/fibers/bin/linux-ia32-v8-3.14/fibers.node`
However, I see that the fibers.node that is throwing the error at runtime is not the same one as was compiled, and I assume that's the source of the problem.
Compiled:
.../linux-ia32-v8-3.14/fibers.node
Used at runtime and fails:
.../linux-ia32-v8-5.0/fibers.node
So I'm guessing and hoping that if I could convince wdio-mocha-framework to use the locally-compiled fibers.node, it would work. My questions are thus:
Would that fix it?
If so, how do I achieve that?
If not, what's the correct direction to take to further understand and fix this error? Perhaps instead of getting 3.14 to be used at runtime, I should be convincing 5.0 to be compiled at install-time? Or ... other?
Your help is most sincerely appreciated.
Update/Edit:
I think I solved this on my own, in case anyone ever finds this poor, dusty old question lying forgotten on the back of a shelf somewhere...
The problem was apparently due to multiple versions of node/node-gyp that were installed in my environment in parallel, and the build process, even though it was started with a newer version of node, was finding node-gyp in the $PATH and that's apparently what caused the old version of fibers to be built. At least, I think so.
Just had this problem recently. I managed to solve it just by uninstalling the current version of Node.JS (I had the most recent, in this case 9.5.0) and installing the recommended, in this case 8.9.4. and the issue is gone. hope this helps someone.
My current npm version is 3.7.3 . Previously, only the required packages were getting installed in my node modules. But right now they have all flattened and have 100 + folders visible when I look into node modules. I prefer the older way where you could go into individual folders and see their dependencies.
here is a similar thread:
Why does npm install many packages into "/node_modules" instead of only one?
I tried running npm uninstall without much success.
Basically, you are out of luck... NPM does not provide any configuration options regarding this. It will nest dependencies if it must in order to resolve version conflicts, but only in this case. Your only option is to downgrade NPM (not recommended). However, if you just need to see the dependencies nested for informational reasons, you can use npm ls. It will draw you a graph.
See this relevant NPM issue for more discussion: https://github.com/npm/npm/issues/9809
Now that node js' LTS doesn't include an NPMv2 I found myself stuck with this issue again.
For those of you also caught out, the link that #KevinBurdett mentioned, also has some answers.
You can force downgrade npm using npm itself (using sudo or equivalent for this). From https://github.com/npm/npm/issues/9809#issuecomment-179702479:
as root I simply do npm install -g 'npm#<3' on my system every time I
a new version of Node comes out; your mileage might vary, but it's
fairly trivial to "downgrade" :-)
Another alternative is to use the Node Version Manager (NVM): https://github.com/creationix/nvm. Your mileage may vary depending upon personal config/preferences/platform.
That said, npm 3 and the issue of flat dependency trees will be with us from hereafter... It's probably high time to start accepting that change.
My personal grudge with this is that it makes the node_modules folder incredibly difficult to work with in an IDE, especially when you need to look at the implementation of your immediate dependent modules, without first wading through 100's of sub-sub modules that are irrelevant to me. It seems that I'm not alone in this matter when you read the comments in the issue. It only leads me to question the viability of npm itself when such changes are made without a proper migration from old to new systems. For me, npm2 will always be king.
I get invalid packages installing, even if the installation is a success. Btw, this question is related to the answer - question about versioning
npm install serialport
These are packages which is stuck far in the dependency tree.
npm ERR! invalid: readable-stream#1.0.27-1 /Users/snorre edwin/Code/raspberry-node-server/node_modules/serialport/node_modules/node-pre-gyp/node_modules/tar-pack/node_modules/readable-stream
npm ERR! invalid: string_decoder#0.10.25-1 /Users/snorre edwin/Code/raspberry-node-server/node_modules/serialport/node_modules/node-pre-gyp/node_modules/tar-pack/node_modules/readable-stream/node_modules/string_decoder
This ends up causing this error in my browser:
Uncaught TypeError: Cannot read property '_ansicursor' of undefined
Is there any way to sort up in this npm problem? Can I avoid these prerelease packages?
The github answere below gave me a lot of insight into npm and I thought I had to dig somewhere else for the issue. But it acctually just seemed like serialport does not work very well, anymore, with browserify. It used to work because i used if for two months, but something changed. When im saying it out loud, it just sounds stupid anyway. So dont browserify serialport.
I recieved an answere on github, issue answere, thought i would share it with the rest who might wonder:
The change in handling prerelease versions in semver#4 is one of the primary motivators for the major version bump to npm#2. All versions of npm 2 are affected by this change, which, put briefly, ensures that all version information to the right of - in version strings is ignored when doing semver range matching. When you upgrade from npm#1 to npm#2, it's normal to see some irregularities show up when you run npm -g ls, and since some packages are distributed as self-contained installs via the use of bundledDependencies, they may come out of the package in a state that is inconsistent with npm#2's rules.
While this won't always work, most of the time the easiest way to fix these issues is simply to uninstall and reinstall the affected package. For packages that ship with bundledDependencies, if you really want to get everything cleaned up, you can cd into the node_modules folder containing the version of the package with the noisy prerelease dependency version and just run npm install problemDependency, and it will use the newest version of that dependency that matches the semver range for that particular package.
Re: your second question, semver range checking is done semantically, not lexically, so 1.0.31 should match with npm#2:
% semver -r '~1.0.2' 1.0.26 1.0.27-1 1.0.31
1.0.26
1.0.31
I suspect that the behavior you're seeing is due to a bundledDependency included in the package tarball.
All of this is documented, so I'm going to close this issue. I hope this clears things up for you!