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.
Related
I have a slight problem with a basic Node.JS method. When I'm trying to use "require()' method to import any downloaded (with 'npm install ..) module/library, I get a Visual Studio Code message that asks 'to convert 'require'(which is a Common JS module) into ES. If I do it, it transforms 'require()' into 'import..' though I want keep using 'require()'. Why is it so ? I read somewhere that Common JS is already included in the Node.JS environment though.
Then, when trying to compile my index.js file (with 'node index.js'), I obviously get an error about 'require' not recognized method.
Error [ERR_REQUIRE_ESM]: require() of ES Module C:\Users...index.js from C:\Users...index.js not supported.
I tried then to install Webpack to fix this issue, but nothing change. I also kind of installed CommonJS (npm i common-js)..
Another common answer was to remove 'type':'module' from package.json file which normally should allow to use 'require', but I don't even have such a line in the file.
On top of that I've recently read that 'require' is not compatible with browser development tools (it's ok). But I'm trying to import a downloaded module/npm package in VSC terminal, not even in a browser.
As you understand I'm new to Node.JS, but I don't really get what's going on in this case...
Recently I have updated the node version to 16+. Prior to that, I was able to trigger the yarn build command to create the build of my project.
But after installation of node 16+, the yarn build command is throwing the following errors
./lib/view-registration.js
Module not found: Error: Can't resolve 'hoisted/#msdyn365-commerce-modules/wishlist/dist/lib/modules/wishlist-items/wishlist-items.view.js' in 'H:\source\D365_eCommerce\lib'
# ./lib/view-registration.js 5:112769-113063
# ./node_modules/#msdyn365-commerce/bootloader/entry/client.js
# multi ./node_modules/#msdyn365-commerce/bootloader/entry/webpack-public-path.js ./node_modules/#msdyn365-commerce/bootloader/entry/client
It seems like it is trying to pick the module from the hoisted folder.
I am new to this concept so have no idea why it is targeting this folder in spite of this it should pick the module from '#msdyn365-commerce-modules/wishlist/dist/lib/modules/wishlist-items/wishlist-items.view.js' directly.
Any explanation would be appreciated.
How can I force it to not pick the module directly from the hoisted folder and use '#msdyn365-commerce-modules/wishlist/dist/lib/modules/wishlist-items/wishlist-items.view.js' directly
Thanks,
Aman
This issue mainly occurred due to the corrupt version of Node.
The only possible solution for this is to make sure that all the dependencies required for Node (16+) are also installed.
We can either download all the dependencies manually or just need to allow the node itself to download all the dependencies at the time of installation.
Thanks,
Aman
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.
I'm have a small npm package which I'm writing in node 9 and using all the latest and greatest features like async/await. I'm also using babel which allows me to use ES6 module imports and exports
Babel also allows me to transpile the package to a target node version. I'm using the node release schedule to define which version of node the package will support and with the the target for the babel compilation. Currently node 4.x is still in maintenance lts stage, so I'm targeting it. Unfortunately this means almost every new feature in JavaScript I'm using gets transpiled.
What I'd like to do is to transpile the package to different targets (4.x, 6.x, 7.x, 8.x, and 9.x currently apply) and have npm choose the appropriate build of the package at install time based on the user's node version. If I'm not mistaken, I've seen apt-get do this with different versions of Ubuntu.
Is this possible with npm?
I'll bump an old thread here. A good option is to use two separate directories and choose the transpiled version depending on process.version.
I'll be trying to do this in scramjet and will be updating the thread along the way. My plan is to use an index.js file like this:
const ver = process.version.slice(1).split('.');
module.exports = require(+ver[0] > 8 && +ver[1] > 3 ? 'lib/index' : 'lib-6/index')
This should do for now, but since I also have some v10+ targeted code (especially DataStream.from(async function*() { ... }) which has some ifs in it I may want to extend it later and use a table.
What's important here is that the code above runs once (unless you clear require cache) and mostly in compile time so it has minimal influence over your 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.