Handlebars: Access has been denied to resolve the property in console logs during unit tests in React

[djErock]

Everytime I run my unit tests since upgrading to Babel 7, I see a long list of console logs with this message in them...

  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');

How do I make this go away?

What is most disturbing is you disabled a lint rule in your release to make it happen...

*Note: It only happens when running coverage on untested files...

[nknapp]

The warning is printed because the code coverage report is actually not working correctly. Istanbul-reports have been broken with the 4.6.0 release of handlebars and the warning is printed to point to the correct handlebars configuration to change on such cases.

See #1636 for details and #1633 for more details about the reason for the breaking change in a minor version bump. You can also open the link in the warning to see how to make it go away, but if you are using handlebars as third or fourth level dependency, I guess you can't.

Sorry about the hassle, but I still believe it was the right thing to do.

[nknapp]

That link also contains links to all the security advisories that ultimately led to the changes we made.

[antempus]

I also have this issue as well and opening the link does nothing as there is no webserver running.

While I do understand, after looking into the other issues, why the change was needed, introducing this as a breaking minor change is against SEMVER Spec #8.

It's going to be especially challenging for those, like my team, that use handlebars as a 5th level dependency jest -> @jest/core -> @jest/reporters -> istanbul-reports -> handlebars

When jestjs/jest#9355 is resolved/released and the move to using instanbul 3.0.0 is complete this issue should not be a problem as there is no dependency on handlebars.

Is there any guidance on how to fix this in the interim? poking the isntanbul team to pin to a previous version?

[nknapp]

I could try to change so that the log output is only printed once.

Is this breaking your build or just log annoyingly much data?

[nknapp]

I think you could also disable the HTML coverage reporter until this is resolved.

[nknapp]

Istanbul is also working on a backport of the new HTML reporter to 2.x

[nknapp]

An new version of "istanbul-reports" is published, mentioned in #1636

[nknapp]

@antempus the logged message should be something like... Argh, I just noticed I copied the link-url while running the local dev-server of the Handlebars homepage.

I'll fix it in the next release.

[djErock]

I could try to change so that the log output is only printed once.

Is this breaking your build or just log annoyingly much data?

Super annoying as in most cases it prints 1000+ times ... If you could just say access denied x times and if array is greater than x only print once.... That would make this much more tolerable

[nknapp]

I have just pushed a change that will log it only once per property. And fix the link url.

[nknapp]

and it's released 4.7.1

[aromot]

Hello, I'm using handlebars 4.7.1 with webpack, i.e through handlebars-loader. After reading the handlebars API ref, I've changed my webpack loader config:

{
  test: /\.hbs$/,
  loader: 'handlebars-loader', 
  query: {
    precompileOptions {
      allowProtoPropertiesByDefault: true,
      allowProtoMethodsByDefault: true
    },
    helperDirs: [path.join(__dirname, 'src/view/helpers')]
  }
},

But I still get the errors:

logger.js:34 Handlebars: Access has been denied to resolve the property "format" 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

Any clue to fix that?

[nknapp]

Check the docs for the handlebars-loader on how to pass runtime options. It is not a compile option but runtime.

[nknapp]

You need to pass the options as second parameter to the template function that is the result of your import.

[aromot]

Thank you for your quick answer (sorry for being a bit off subject). I didn't know it is possible to pass options as 2nd param. I tried, it works, but, if possible, I'd like to declare it once for all in my wekpack config.

For those who would be interested, I opened an issue on the handlebars-loader repo.

[mickela]

The warning is printed because the code coverage report is actually not working correctly. Istanbul-reports have been broken with the 4.6.0 release of handlebars and the warning is printed to point to the correct handlebars configuration to change on such cases.

See #1636 for details and #1633 for more details about the reason for the breaking change in a minor version bump. You can also open the link in the warning to see how to make it go away, but if you are using handlebars as third or fourth level dependency, I guess you can't.

Sorry about the hassle, but I still believe it was the right thing to do.

So what you're saying is that I can't do something like this => Budget: {{budget}} anymore. Okay, what do I write in my code to get the desired result please?

[nknapp]

Not if "parent.hasOwnProperty('budget')" returns false. You can disable that check in a runtime option, but I would suggest creating the input objects such that all relevant properties are own properties.

The problem occur when you are using custom classes as input and my preferred solution would be that you add a method that returns an actual plain javascript object.

If the people writing your templates are the same as people writing the code, you can also disable the safety checks.

The error message contains a link to the documentation that tells you how to so that.

[justinTM]

hi @nknapp thank you for the info. I'm wondering (as a noob-ish handlebars user) what I can do to "[create] the input objects such that all relevant properties are own properties"?

[7-of-9]

This breaks https://github.com/OpenZeppelin/solidity-docgen

[comeab]

i stringgified my obeject with JSON.stringify and I parsed it back with JSON.parse.
Not the best, but it was a quick solution.