Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Joi should not strip non-enumerable properties of an object #1696

Closed
pierreis opened this issue Jan 10, 2019 · 3 comments
Closed

Joi should not strip non-enumerable properties of an object #1696

pierreis opened this issue Jan 10, 2019 · 3 comments
Assignees
Labels
feature New functionality or improvement
Milestone

Comments

@pierreis
Copy link

pierreis commented Jan 10, 2019

Context

  • node version: 11.5.0
  • joi version: 10.6.0
  • environment (node, browser): node
  • used with (hapi, standalone, ...): standalone

What are you trying to achieve or the steps to reproduce ?

Consider the following example code:

const joi = require('joi');
const obj = {foo: 'bar'};
Object.defineProperty(obj, 'test', { value: 42, enumerable: false });
joi.validate(obj, joi.object().keys({}).unknown()).value
// >> { foo: 'bar' }
joi.validate(obj, joi.object().keys({}).unknown()).value.test
// >> undefined

Which result you had ?

Joi strips non-enumerable properties of the object.

What did you expect ?

Unknown properties being allowed, the object should be returned unaffected. Own object properties should not be stripped from the returned value.

Use-case

I do have a validator that takes an object, and validates that one of its values is an ORM model:

Joi.object().type(MyModel)

This works fine. The ORM defines on the model a few methods, that are not enumerable, and these are kept at this point.

If, however, I try to validate one of the values of a model instance:

Joi.object().type(MyModel).keys({ something: Joi.string() }).unknown()

The ORM-defined methods are stripped from the resulting value.

@WesTyler
Copy link
Contributor

I don't have the chance to test it just now, but try adding .raw()

From the source it looks like it should use the original object instead of a cloned and possibly-coerced one

@pierreis
Copy link
Author

Thanks. I’ll try this ; I’m not sure it will help my specific use-case as I rely on an extension to coerce an object to ORM model if needed though.

@jaulz
Copy link

jaulz commented Apr 29, 2019

PR #1796 could solve this

@hueniverse hueniverse self-assigned this Jun 1, 2019
@hueniverse hueniverse added the bug Bug or defect label Jun 1, 2019
@hueniverse hueniverse added this to the 16.0.0 milestone Jun 1, 2019
@hueniverse hueniverse added the feature New functionality or improvement label Jun 1, 2019
@hueniverse hueniverse removed the bug Bug or defect label Jun 1, 2019
@hueniverse hueniverse added the v16 label Aug 10, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Feb 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature New functionality or improvement
Projects
None yet
Development

No branches or pull requests

4 participants