I get this when I am running jest
:
> cross-env NODE_ENV=test jest
[vue-jest]: no .babelrc found, skipping babel compilation
[vue-jest]: no .babelrc found, skipping babel compilation
PASS tests/pages/index.spec.ts (5.069s)
unit tests for Index view
โ should have three comments (36ms)
โ should load new comments on actions (41ms)
snapshot test for Index view
โ should match the snapshot (72ms)
PASS tests/components/action-bar.spec.ts (5.061s)
unit tests for ActionBar component
โ should have one button (42ms)
โ should call fetchComments action (7ms)
โ should match the snapshot (33ms)
PASS tests/components/comment.spec.ts
unit tests for Comment component
โ should have valid props (28ms)
โ should have two buttons (13ms)
โ should have correct values (12ms)
โ should change rating: {"delta": 1, "styleName": "comment-positive"} (10ms)
โ should change rating: {"delta": -1, "styleName": "comment-negative"} (4ms)
snapshot tests for Comment component
โ should match the snapshot (17ms)
-------------------------|----------|----------|----------|----------|----------------
---|
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line
#s |
-------------------------|----------|----------|----------|----------|----------------
---|
All files | 95.97 | 82.35 | 90 | 96.94 | |
components | 95.45 | 100 | 80 | 95 | |
ActionBar.vue | 100 | 100 | 100 | 100 | |
AppLogo.vue | 100 | 100 | 100 | 100 | |
Comment.vue | 91.67 | 100 | 50 | 90.91 | 60 |
logic | 100 | 100 | 100 | 100 | |
store.ts | 100 | 100 | 100 | 100 | |
tokens.ts | 100 | 100 | 100 | 100 | |
logic/comments | 95.12 | 77.78 | 100 | 100 | |
models.ts | 100 | 100 | 100 | 100 | |
module.ts | 94.87 | 77.78 | 100 | 100 | 50,56 |
logic/comments/services | 100 | 100 | 100 | 100 | |
api.ts | 100 | 100 | 100 | 100 | |
mixins | 100 | 100 | 100 | 100 | |
typed-store.ts | 100 | 100 | 100 | 100 | |
pages | 83.33 | 100 | 50 | 81.82 | |
index.vue | 83.33 | 100 | 50 | 81.82 | 56,57 |
plugins | 100 | 100 | 100 | 100 | |
type-di.ts | 100 | 100 | 100 | 100 | |
store | 100 | 50 | 100 | 100 | |
index.ts | 100 | 50 | 100 | 100 | 30 |
-------------------------|----------|----------|----------|----------|-------------------|
Handlebars: Access has been denied to resolve the property "statements" because it is not an "own property" of its parent.
You can add a runtime option to disable the check or this warning:
See http://localhost:8080/api-reference/runtime-options.html#options-to-control-prototype-access for details
...
Problem part:
Handlebars: Access has been denied to resolve the property "statements" because it is not an "own property" of its parent.
You can add a runtime option to disable the check or this warning:
See http://localhost:8080/api-reference/runtime-options.html#options-to-control-prototype-access for details
It is actually VERY long. It has like hundreds of lines.
Full log is here: https://travis-ci.com/wemake-services/wemake-vue-template/builds/143977902#L759
Steps to reproduce the behavior:
npm i
npm test
I expect the tests to pass without any warnings.
ยป npx envinfo --preset jest
npx: installed 1 in 1.988s
System:
OS: macOS Mojave 10.14.5
CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
Binaries:
Node: 12.14.0 - ~/.nvm/versions/node/v12.14.0/bin/node
Yarn: 1.9.4 - /usr/local/bin/yarn
npm: 6.13.4 - ~/.nvm/versions/node/v12.14.0/bin/npm
npmPackages:
jest: ^24.9.0 => 24.9.0
This is about the most annoying thing of all time... I posted an issue on handlebars github as I tracked down this -->
function checkWhiteList(protoAccessControlForType, propertyName) {
if (protoAccessControlForType.whitelist[propertyName] !== undefined) {
return protoAccessControlForType.whitelist[propertyName] === true;
}
if (protoAccessControlForType.defaultValue !== undefined) {
return protoAccessControlForType.defaultValue;
}
// eslint-disable-next-line no-console
logger.log('error', 'Handlebars: Access has been denied to resolve the property "' + propertyName + '" because it is not an "own property" of its parent.\n' + 'You can add a runtime option to disable the check or this warning:\n' + 'See http://localhost:8080/api-reference/runtime-options.html#options-to-control-prototype-access for details');
return false;
}
They disabled a lint rule and it got into the release... SMDH
Issue in Jest is with this dependency -->
"istanbul-reports": {
"version": "2.2.6",
"resolved": "https://artifactoryprod.es.ad.adp.com/artifactory/api/npm/caet-npm/istanbul-reports/-/istanbul-reports-2.2.6.tgz",
"integrity": "sha1-e08mYNgrKTA6j+YJH4ykvwWNoa8=",
"dev": true,
"requires": {
"handlebars": "^4.1.2"
}
},
Had to install
npm i -D [email protected]
as a dev dependency and the console logs went away... Pretty klugey answer but will do until one of the two sides figures it out... or someone submits a PR to handlebars... * slowly whistles and walks away
I'm having the same issue and just tried installing handlebars as a dev dependency but I'm still getting the warnings.
I'm having the same issue and just tried installing handlebars as a dev dependency but I'm still getting the warnings.
rm -rf node_modules && rm -rf package-lock.json && npm i && npm test
Remove the caret in front of 4.5.0 in package.json as well
Just tried the above solution, still displaying all the warnings
I'm having the same issue and just tried installing handlebars as a dev dependency but I'm still getting the warnings.
rm -rf node_modules && rm -rf package-lock.json && npm i && npm test
Remove the caret in front of 4.5.0 in package.json as well
Just tried the above solution, still displaying all the warnings
I'm having the same issue and just tried installing handlebars as a dev dependency but I'm still getting the warnings.
rm -rf node_modules && rm -rf package-lock.json && npm i && npm test
Remove the caret in front of 4.5.0 in package.json as well
Can you do a find in your package-lock/yarn-lock for which handlebars version is installed?
I have the exact same problem, except I don't even get coverage reports. It just spams hundreds of lines, and the final report makes the html file with the correct color coding (for percentages, like green red, etc) but the numbers are not there.
Also tried the suggestions above, made no difference. My yarn.lock has handlebars as a dev dependency at 4.70
I have the exact same problem, except I don't even get coverage reports. It just spams hundreds of lines, and the final report makes the html file with the correct color coding (for percentages, like green red, etc) but the numbers are not there.
Also tried the suggestions above, made no difference. My yarn.lock has handlebars as a dev dependency at 4.70
I had the same issue... Downgrading Handlebars did the trick and now all my report is populated with data again and not just color codes.
I have the exact same problem, except I don't even get coverage reports. It just spams hundreds of lines, and the final report makes the html file with the correct color coding (for percentages, like green red, etc) but the numbers are not there.
Also tried the suggestions above, made no difference. My yarn.lock has handlebars as a dev dependency at 4.70I had the same issue... Downgrading Handlebars did the trick and now all my report is populated with data again and not just color codes.
I can't seem to downgrade it, I put in my package.json to install a specific version and it will install that version as well as the 4.7.0 version.
I have the exact same problem, except I don't even get coverage reports. It just spams hundreds of lines, and the final report makes the html file with the correct color coding (for percentages, like green red, etc) but the numbers are not there.
Also tried the suggestions above, made no difference. My yarn.lock has handlebars as a dev dependency at 4.70I had the same issue... Downgrading Handlebars did the trick and now all my report is populated with data again and not just color codes.
I can't seem to downgrade it, I put in my package.json to install a specific version and it will install that version as well as the 4.7.0 version.
rm -rf node_modules && rm -rf package-lock.json && npm i && npm test
Remove the caret in front of 4.5.0 in package.json as well
Thanks for your help! However, 4.5.0
is reported as unsafe.
+ [email protected]
updated 1 package and audited 899407 packages in 22.265s
54 packages are looking for funding
run `npm fund` for details
found 6 high severity vulnerabilities
run `npm audit fix` to fix them, or `npm audit` for details
See https://github.com/wycats/handlebars.js/issues/1636. I think the problem is known and in work.
Yeah, from Jest's perspective this is essentially a duplicate of #9388 (and the linked handlebars issue). The difference is that instead of silently failing (4.6.0), handlebars is printing a warning (4.7.0).
To avoid the warning you can disable the html coverage reporter by replacing the lcov
reporter with lcovonly
(e.g. coverageReporters: ['json', 'text', 'lcovonly', 'clover']
).
You can also force a version of handlebars older than 4.6.0
(by putting "handlebars": "~4.5.3"
in your package.json and making sure to dedupe dependencies) and the html reporter will work again, if you wanna use it.
The real fix is suggested in #9388 - please help by testing the version of istanbul posted about there.
@SimenB
Replacing lcov
reporter with lcovonly
worked for me:
// jest.config.js
module.exports = {
preset: 'ts-jest',
testEnvironment: 'node',
coverageThreshold: {
global: {
branches: 80,
functions: 80,
lines: 80,
statements: 80
}
},
coverageReporters: ['json', 'lcovonly', 'text', 'clover']
};
Thanks, @SimenB !
I have the exact same problem, except I don't even get coverage reports. It just spams hundreds of lines, and the final report makes the html file with the correct color coding (for percentages, like green red, etc) but the numbers are not there.
Also tried the suggestions above, made no difference. My yarn.lock has handlebars as a dev dependency at 4.70I had the same issue... Downgrading Handlebars did the trick and now all my report is populated with data again and not just color codes.
I can't seem to downgrade it, I put in my package.json to install a specific version and it will install that version as well as the 4.7.0 version.
rm -rf node_modules && rm -rf package-lock.json && npm i && npm test
Remove the caret in front of 4.5.0 in package.json as well
Didn't work, it appears Vuetify also has several dev dependencies that install handlebars at a higher version. I was able to workaround that by editing the yarn.lock file to make sure every dependency that uses handlebars was locked to 4.5.0, then installed again.
If using yarn you can use resolutions
. Might be npm has that as well, I don't remember
I have the same issue. Hope it will be resolved soon.
If you are using older versions of JEST/JEST-CLI, and facing the same issue:
Then add the following code in package.json under dependencies:
"resolutions": {
"handlebars" : "4.5.0"
},
after installation, the lock files looks:
[email protected], handlebars@^4.0.3:
version "4.5.0"
resolved "https://registry.yarnpkg.com/handlebars/-/handlebars-4.5.0.tgz#d5d902dfe0f266ef79f3921b89233a5f611cdea7"
dependencies:
eslint-plugin-compat "^3.3.0"
neo-async "^2.6.0"
optimist "^0.6.1"
source-map "^0.6.1"
optionalDependencies:
uglify-js "^3.1.4"
With handlebars 4.7.1 there should be a lot less warnings. Only a couple.
Since some of the issues are related to JEST and coverage of tests. I updated my project's jest.config.js
file and commented out the coverageDirectory
item. Still not a fix if you want coverage for your tests - but it did remove the error messages while running the tests.
module.exports = {
name: 'common',
preset: '../../jest.config.js',
// coverageDirectory: '../../coverage/libs/common',
snapshotSerializers: ['jest-preset-angular/AngularSnapshotSerializer.js', 'jest-preset-angular/HTMLCommentSerializer.js'],
};
I'm using jest v24 and still having the problem, so the closed issue #9388 does not appear to be the solution. In fact I can't see why that issue was closed, since the html report is still broken.
It's not broken, just update your version of istanbul-reports
. Did you try the steps?
The suggested fix was to update to Jest v24, which I have done ("jest": "^24.9.0"
, to be precise). I've also done a yarn clean
and yarn install
. Looking at yarn lock, I see that the version of istanbul-reports
being installed is now "2.2.6"
pulled in by "@jest/reporters@^24.9.0"
)
Any suggestions would be most welcome.
The suggested fix for people using a version older than jest 24 was to install 24. Please read the whole issue, e.g. https://github.com/facebook/jest/issues/9388#issuecomment-573371732
OK I have it working now. The suggestion to delete the existing istanbul-reports
from yarn.lock
actually had no effect, but I did make it work as follows:
rm yarn.lock
yarn clean
yarn
(to regenerate the yarn.lock
file)istanbul-reports
from the generated yarn.lock
to a temp fileyarn.lock
yarn
again (this resolved the new dependency for html-escaper@^2.0.0:
)The pasted lines, in case anyone wants them:
istanbul-reports@^2.2.6:
version "2.2.7"
resolved "https://registry.yarnpkg.com/istanbul-reports/-/istanbul-reports-2.2.7.tgz#5d939f6237d7b48393cc0959eab40cd4fd056931"
integrity sha512-uu1F/L1o5Y6LzPVSVZXNOoD/KXpJue9aeLRd0sM9uMXfZvzomB0WxVamWb5ue8kA2vVWEmW7EG+A5n3f1kqHKg==
dependencies:
html-escaper "^2.0.0"
So it seems that since jest/reporters@^24.9.0
still specifies istanbul-reports@^2.2.6
that yarn won't fetch anything later even if it exists, except when there is no lock file to begin with. Sounds like a bug in yarn to me, but the above workaround does help.
If still relevant
I had such errors:
Handlebars: Access has been denied to resolve the property "img" because it is not an "own property" of its parent. You can add a runtime option to disable the check or this warning:
See https://handlebarsjs.com/api-reference/runtime-options.html#options-to-control-prototype-access for details
It happened after getting data from MongoDB and while trying to render this data using handlebars. I got the data by 'find' method: const data = await Data.find()
Then I fixed it to: const data = await Data.find({}).lean()
and it worked.
Data
- name of data model in MongoDB
This issue can be resolved by installing handlebars 4.5 with this command-
npm i -D [email protected]
@rahulaggarwal11 going back to [email protected]
is not the intended solution. You won't get security updates anymore if you do that.
If you are using Handlebars explicitly, you should follow the instructions behind the link in the error message, although the solution that @grok21 used is even better when using MongoDB.
If you are using a package that depends on Handlebars, the maintainers should follow the instructions.
Most helpful comment
@SimenB
Replacing
lcov
reporter withlcovonly
worked for me:Thanks, @SimenB !