Invalid type error while trying to parse process.env object

[vladshcherbin]

Code:

import process from 'node:process'
import { object, parse, string } from 'valibot'

console.info(typeof process.env)
console.info(process.env.NODE)
console.info('---')

parse(
  object({
    NODE: string()
  }),
  process.env
)

Result:

• same error with looseObject and strictObject
• no error in 0.30
• no error with spread object copy:

parse(
  object({
    NODE: string()
  }),
  { ...process.env }
)

valibot - 0.31.0-rc.0
node - 20.10.0

[vladshcherbin]

Cause: Last check from object doesn't pass.

[fabian-hiller]

I made the check stricter to only match plain objects. I don't know why process.env is not a plain object. Object.getPrototypeOf(process.env).constructor.name returns an empty string. Not sure if we should make the check less strict because of this.

{ ...process.env } works because it returns a plain object with all the properties of process.env.

[vladshcherbin]

I also have no idea and it'll be strange if it doesn't pass.

Out of interest quick test:

• zod - pass
• https://www.npmjs.com/package/is-plain-object - doesn't pass
• https://www.npmjs.com/package/is-plain-obj - doesn't pass

[fabian-hiller]

If others encounter the same problem, I would like to hear their opinions and whether the workaround is sufficient.

[fabian-hiller]

From #602. Happy to hear your feedback.

There are other problems with the current plain object check, for example in #587, but I am not sure if Valibot is the problem. Normally, this should not be a problem. We could remove the input.constructor === Object check to make it less strict, but then any object that is not null will be accepted. In practice, this is usually not a problem because we never return the original object. So, strictly speaking, the validation is still safe. Therefore, I might make the validation less strict so as not to have to deal with special JS runtime behavior that we can't control.

One problematic case that just came to my mind that could lead to unexpected behavior is our looseObject and objectWithRest schemas, as they can add unexpected data to the output if the wrong object types are passed.

[fabian-hiller]

This is fixed in v0.31.0-rc.6

[vladshcherbin]

Perfect, thank you!

I think the fix is good until a valid non-false object assumption is found 👍