Lots of handlebars warnings with text+coverage reporter

[sobolevn]

🐛 Bug Report

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

To Reproduce

Steps to reproduce the behavior:

1. Create new app: https://github.com/wemake-services/wemake-vue-template
2. Install deps with npm i
3. Run npm test

Expected behavior

I expect the tests to pass without any warnings.

envinfo

» 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 

[djErock]

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 handlebars@4.5.0

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

[shellyhu3]

I'm having the same issue and just tried installing handlebars as a dev dependency but I'm still getting the warnings.

[djErock]

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

[silver-xu]

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

[djErock]

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?

[Nonary]

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

[djErock]

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.

[Nonary]

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 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.

[djErock]

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 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

[sobolevn]

Thanks for your help! However, 4.5.0 is reported as unsafe.

+ handlebars@4.5.0
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

[nknapp]

See handlebars-lang/handlebars.js#1636. I think the problem is known and in work.

[SimenB]

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.

[EstebanBorai]

@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 !

[Nonary]

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 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.

[SimenB]

If using yarn you can use resolutions. Might be npm has that as well, I don't remember

[Shaquu]

I have the same issue. Hope it will be resolved soon.

[tharunhpe]

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:

handlebars@4.5.0, 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"

<NOTE: Only works if you are using yarn, didnt test it with npm>

[nknapp]

With handlebars 4.7.1 there should be a lot less warnings. Only a couple.

[buildmotion]

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'],
};

[OldManLink]

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.

[SimenB]

It's not broken, just update your version of istanbul-reports. Did you try the steps?

[OldManLink]

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.

[SimenB]

The suggested fix for people using a version older than jest 24 was to install 24. Please read the whole issue, e.g. #9388 (comment)

[OldManLink]

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)
• copy the lines for istanbul-reports from the generated yarn.lock to a temp file
• restore the deleted yarn.lock
• paste in the saved lines
• run 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.

[grok21]

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

[rahulaggarwal11]

This issue can be resolved by installing handlebars 4.5 with this command-
npm i -D handlebars@4.5.0

[nknapp]

@rahulaggarwal11 going back to handlebars@4.5.0 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.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.