Short intro: We are starting to use npm ci for a more reliable installation of dependencies for our react application, instead of install. But we have been noticing some strange promise rejection behavior when using ci.
Description:
When running npm ci in a node environment with NODE_ENV set to development, we receive hundreds of promise warnings from the Bluebird promise library:
(node:95984) Warning: .then() only accepts functions but was passed: [object Object]
I am curious whether these are coming from npm CI's code itself, as we have never seen these errors except when using npm CI.
You can also see in their source code that NPM is using Bluebird Promise library version 3.5.3.
To test this, I have incrementally removed all of the main and dev dependencies in our package.json, generating lock files and running npm ci to see if it originated from any specific packages, but it occurred every single time down to the last package (and alternate single packages).
I have also created an entirely separate npm repo and installed a package (react-scripts#latest), generated a lock file, and on running npm ci received the same promise warnings.
We were able to silence the errors on build by setting the environment variable BLUEBIRD_PROMISES=0 per the recommendations of this npm issue, and this did silence the warnings. But we would like to know why this is happening, and if there is something underlying these warnings that deserves more attention than simply silencing them.
Version info:
npm: 6.4.1
node: 10.15.0
I totally missed this (almost year old) question :]
But we would like to know why this is happening,
Bluebird has a warning feature where it warns against incorrect usage of promises. NPM uses bluebird internally and NPM has incorrect usage inside its own code base at some places.
The particular warning happens when you .then with a non-function which is likely an error.
and if there is something underlying these warnings that deserves more attention than simply silencing them.
You can silence them in general with environment variables or safely ignore them.
Related
When running my test suite using Jest, I encountered warnings that asked me to update packages:
npm WARN deprecated jest-dom#2.1.1: 🚨 jest-dom has moved to #testing-library/jest-dom. Please uninstall jest-dom and install #testing-library/jest-dom instead, or use an older version of jest-dom. Learn more about this change here: https://github.com/testing-library/dom-testing-library/issues/260 Thanks! :)
npm WARN deprecated react-testing-library#5.9.0: 🚨 react-testing-library has moved to #testing-library/react. Please uninstall react-testing-library and install #testing-library/react instead, or use an older version of react-testing-library. Learn more about this change here: https://github.com/testing-library/dom-testing-library/issues/260 Thanks! :)
In package.json I changed the following
"jest-dom": "^2.1.1",
"react-testing-library": "^5.3.0"
to
"#testing-library/jest-dom": "^5.11.1",
"#testing-library/react": "^10.4.7"
and of course the import statements from
import "jest-dom/extend-expect";
to
import "#testing-library/jest-dom";
etc.
After I removed the old ones and added the new one, I got multiple error that makes my tests fail (only in my Semaphore CI setup, not on my local machine).
FAIL src/redux/actions/tests/myActions.test.js
● Test suite failed to run
Jest encountered an unexpected token
This usually means that you are trying to import a file which Jest cannot parse, e.g. it's not plain JavaScript.
By default, if Jest sees a Babel config, it will use that to transform your files, ignoring "node_modules".
Here's what you can do:
• To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
• If you need a custom transformation specify a "transform" option in your config.
• If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.
You'll find more details and examples of these config options in the docs:
https://jestjs.io/docs/en/configuration.html
Details:
/home/semaphore/my-app/client/node_modules/#testing-library/dom/dist/helpers.js:44
} catch {// not using Jest's modern fake timers
^
SyntaxError: Unexpected token {
at ScriptTransformer._transformAndBuildScript (node_modules/jest-runtime/build/script_transformer.js:403:17)
at Object.<anonymous> (node_modules/#testing-library/dom/dist/pretty-dom.js:13:16)
at Object.<anonymous> (node_modules/#testing-library/dom/dist/config.js:11:18)
I am not a frontend developer, so I am happy to hear what more information is needed to facilitate help. Thanks a lot!
The error refers to optional catch binding, which is modern JS feature and supported since Node 10. This means that #testing-library/dom package doesn't support older Node versions, this can be confirmed by checking engines section in its package.json.
A preferable solution is to update Node.js because 8 reached the end of life. Alternatively, the package can be downgraded to lower major version or transpiled by white-listing it in transformIgnorePatterns, as the error suggests.
#Estus's answer is absolutely right, and I voted it up. Just wanted to add the actual fix if you are also using Semaphore for your CI, so you don't need to spend more time investigating like I did.
Make sure your current node version is at least the latest stable LTS, and that the version you're using locally is the version your tests pass with
Generate an .nvmrc file if you don't have one already: node -v > .nvmrc
Make sure you call nvm use in every block of your semaphore.yml.
i.e. use an extrapolated for-your-project, version of this: https://github.com/semaphoreci-demos/semaphore-demo-javascript/blob/master/.semaphore/semaphore.yml.
That will ensure your node versions are in sync, and should resolve any "SyntaxError: Unexpected token {" errors you're encountering in CI provided the same tests are passing locally. If you don't specify the node version, Semaphore uses v8.17.0 as the default (https://docs.semaphoreci.com/ci-cd-environment/ubuntu-18.04-image/#javascript-via-node-js)! Hence why anyone who doesn't specify the version will encounter this error when upgrading any Jest libs.
We are using Gulp with browserify, and I am having a problem diagnosing an error. Browserify runs, reporting no problems, however, many of the scripts that should have been concatenated into my output js file are missing.
We have found that this can happen if we are missing an npm package (if we need to run npm install), or if there is something wrong with an npm package. The past couple of times it has happened, we have been lucky in that we had only just added 1 package and so we immediately knew where to look.
Now, I have it failing on a dev machine (by fail, I mean that my output .js file is 1/10th the size it should be an missing many js files, but no errors reported). I am not sure which package it is failing on, and I am getting no diagnostics.
I tried hooking .on('error') as described here: https://stackoverflow.com/a/24817446/67038, but there was no additional output.
The output from the Visual Studio Task Runner Explorer looks like this:
[18:17:21] Using gulpfile C:\git\...\Gulpfile.js
[18:17:21] Starting 'browserify:local'...
[18:17:24] Finished 'browserify:local' after 2.63 s
[18:17:24] Starting 'build:local'...
[18:17:24] Finished 'build:local' after 31 ms
Process terminated with code 0.
What can I do to get additional information from Browserify? Is there some sort of logging that I can turn on?
The problem you experienced was caused by the tsify plugin.
Prior to version 1.0.4, there were a number of path-related bugs that could result in empty modules being emitted without any errors being reported to Browserify. These bugs have been fixed and errors are now emitted to Browserify in situations that would have previously resulted in an empty module.
If I write a package I am certain requires Node 4 or higher, I don't want it to be installable with older versions.
I know about the package.json engines field, but that's just advisory (only causes a warning). And enginesStrict has been deprecated.
So what can I do?
One idea is to have a preinstall script that checks the Node version and errors if it's not high enough, preventing installation from continuing. Are there any problems with doing that? And is there a better way?
If you want a good experience, make your CLI entrypoint standard ES5 and CommonJS, detect the node version (process.version), and print a detailed and helpful message then exit non-zero. Keep in mind your module may get installed with some node version then the user futzes with nvm or their PATH or whatever and then runs your code under a different version. Thus I think failing nicely at run time is the most important thing. You can also choose to fail at install time if you like.
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!
Full error/warning log: http://pastebin.com/xNjC4FDr
I had problem as well when I tried to install MongoDB, I have made SO question of it but, that was only warnings, so I could ignore it. But this time it's not only warnings, but also red error.
What do I have to do? Is my Nodejs messed up because I've installed Visual Studio Tools for NodeJS in the past? Or is this normal behavior? What can I do about this, I prefer not to see errors/warnings when I install something on NPM.
The problem is that hiredis does not support Windows currently. The link to the Windows-compatible fork in the hiredis readme seems to be outdated (last commit in 8/2013 as of this writing), so you may be out of luck.
However hiredis is not required by the redis module, it's an optional dependency that just makes parsing the redis protocol faster than the pure JavaScript parser that is bundled with redis. You may see a similar thing with other modules that have optional dependencies like this. Typically if you see the module tree outline at the end of the console output, that means the module installation was successful.