error when try run test
● Test suite failed to run
Jest encountered an unexpected token
Jest failed to parse a file. This happens e.g. when your code or its
dependencies use non-standard JavaScript syntax, or when Jest is not
configured to support such syntax.
Out of the box Jest supports Babel, which will be used to transform
your files into valid JS based on your Babel configuration.
By default "node_modules" folder is ignored by transformers.
Here's what you can do: • If you are trying to use ECMAScript
Modules, see https://jestjs.io/docs/ecmascript-modules for how to
enable it. • If you are trying to use TypeScript, see
https://jestjs.io/docs/getting-started#using-typescript • 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/configuration For information about
custom transformations, see:
https://jestjs.io/docs/code-transformation
Details:
D:#workspace\monotest\packages\one\build\index.js:1
({"Object.":function(module,exports,require,__dirname,__filename,jest){import
{ v4 as uuid } from 'uuid'; Additional context No response
This is probably too late but for future reference here's what you can do.
In your jest.config.(js|ts) file you can
moduleNameMapper: {
'^uuid$': require.resolve('uuid'),
},
Related
I'm trying to use Jest manual mocking (ref) with built-in Node.js modules that are imported using the node: protocol (ref) in a TypeScript project. I can get this to work by, for example, creating a file in my project called __mocks__/node:fs.ts and calling jest.mock("node:fs"); in my test.
However, node:fs.ts is an invalid file name on Windows due to the colon. So the question is: is there an alternative name that's compatible with Jest manual mocking that works with just calling jest.mock("node:fs");.
I tried two alternatives:
Putting the mocks for builtin modules at __mocks__/node/fs.ts, as expected this didn't work.
I currently landed at the non-ideal solution of mocking builtin modules like jest.mock("node:fs", () => require("../path/to/the/node-fs.mock.ts"));. This works, but is not a nice solution.
For reference, here's a link to a project where I'm having this issue: https://github.com/ericcornelissen/svgo-action/tree/b8a750b3738ba631e7be677ce03a90c90bab2783
I need to override default testID attribute in React Testing Library. Using Jest as a testing framework.
For this, I have followed the steps given here at individual test file level.
Is there any way to have this configuration at global (project) level, so that all the test files in the project will adhere to such custom configuration and will not have need to define custom configuration explicitly at test file level?
If using jest you can add the following in file
import { configure } from 'react-testing-library';
configure({
testIdAttribute: 'data-my-test-id',
});
and include that file in the jest.config.js file in the setupFiles property
setupFiles: [
'<rootDir>/path-to-your-configuration-file.js',
]
https://testing-library.com/docs/dom-testing-library/api-configuration/#introduction
import {configure} from '#testing-library/dom'
configure({
testIdAttribute: 'data-my-test-id',
})
error 'SyntheticUIEvent' is not defined no-undef
for:
handleDocumentKeyUp = (event: SyntheticUIEvent) => {}
I'm getting this for one of the open source projects I'm working on (eslintrc.js) but not in my own app code, but I can't spot the difference or error in linting setup.
What configuration is missing/wrong that would be make eslint unable to find build-in flow types?
If you enable the flowtype/define-flow-type rule in your config, it should tell ESLint about the Flow types.
I have a node.js project that checks itself for code consistency according to rules specified in .eslintrc using gulp and gulp-eslint.
Now, I would like to have it throw custom deprecation warnings when it encounters a certain require:
const someModule = require('myDeprecatedModule');
// Warning: myDeprecatedModule is deprecated. Use myNewModule in stead.
Is this possible in a simple way that will be picked up by IDE's too?
Using .eslint
No custom plugin to be published and installed using npm
Local code only that can be pushed to the repository, nothing global
No custom code in node_modules
The rule no-restricted-modules does exactly this: it disallows requiring certain modules.
The names of the deprecated modules must be coded in the configuration. So in order to disallow the deprecated myDeprecatedModule you would add this setting to your .eslintrc file under the "rules" section.
"no-restricted-modules": ["error", "myDeprecatedModule"]
I don't think it's possible to customize the error message though. That would be possible with a custom plugin.
We have a library that is traditionally client-side only. It uses HTTP Request (or several other dependency libraries) to make REST calls. When using the library, user will initialize with a particular request provider and off they go.
We use webpack in our examples to utilize our library.
It is now extended it to use node-fetch, so if someone wants to use it from nodejs that's supported too.
For people using webpack, webpack is now attempting to pack node-fetch and the require call is failing in the browser. We can get around this with setting an external
"externals" : {
"node-fetch": "{}"
}
Is there a way to define our library so that if the consumer is using webpack target: web, it'd skip the require check for node-fetch? And similarly, if the consumer is using webpack target: nodejs - it needs to include the node-fetch component.
The project in question is https://github.com/OfficeDev/PnP-JS-Core
Thanks for reporting this. So according to This commit and conversation linked to it, the automatic module resolution field (also known as a described-resolve to the webpack resolver instance) changes based on what your target is.
By default, when target is node in your webpack build, resolution in package.json field will default to the main field else, browser field takes priority by default.
More reference https://github.com/webpack/webpack/issues/151
The links provided in the accepted answer & comment show how to do this, so +1 to those, but just to surface it directly here
Is there a way to define our library so that if the consumer is using webpack target: web, it'd skip the require check for node-fetch
Yes. In the library's package.json, add a browser field with the following
"browser": {
"node-fetch": false
}
This provides a hint to webpack and other bundlers that the the node-fetch module should be ignored - i.e. do not even attempt to include it in the bundle - when the target is web. When the target is node, it will be included.
Note that the above relies on the code in the client bundle never using node-fetch. In that sense it can be considered unsafe, because there is no compile-time guarantee of this, and if it happens, it will just error and probably crash your client. If you're absolutely sure it can never be used client-side, though, this is the simplest way to get this done.
For more safety - i.e. if you want the client code to only warn if you try to use node-fetch - you also have the option of providing a shim to the module that the client bundle can include instead, and for instance just log a warning in the shim implementation if it gets used. You do this in the same way, just by providing a path to the shim module instead of false
"browser": {
"node-fetch": "./shims/node-fetch.js"
}