Optional returns the string | undefined type even with the default value set

[NotWorkingCode]

I use the following schema:

export const ConfigSchema = v.object({
    logger: v.object({
        level: v.optional(v.string(), "test"),
        path: v.optional(v.nullable(v.string()), null)
    })
})

When I try to pass the value after validation, I get an error like:
TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.   Type 'undefined' is not assignable to type 'string'.

Type: level?: string | undefined

This is a strange behavior, because when the default value is set, either the value from json or the default value will be returned to me.

[fabian-hiller]

I have tested your schema in my playground and get the following input and output type:

type ConfigInput = {
    logger: {
        level?: string | undefined;
        path?: string | null | undefined;
    };
}

type ConfigOutput = {
    logger: {
        level: string;
        path: string | null;
    };
}

Which version of Valibot are you using? Can you provide more code so I can investigate the problem? Do you have strict set to true in your tsconfig.json?

[NotWorkingCode]

Thank you for your support.

struct is indeed set to true

I tried using both Input and Output - the result is the same.

If you use Input

If you use Output

I am using the latest version: 0.23.0

[NotWorkingCode]

Now I also noticed that path is always equal to a string, although it can be both a string and null

[fabian-hiller]

Is strict set to true in your tsconfig.json?

[NotWorkingCode]

Is strict set to true in your tsconfig.json?

Yes, I wrote it in my second comment.
For clarity, here is the entire tsconfig

[fabian-hiller]

I don’t know what the problem is. In my playground everything works as expected.

[fabian-hiller]

Just noticed that the question marks are missing in ConfigInput. Will fix that in the next release.

[NotWorkingCode]

Thank you very much for your work and such a quick response.

[fabian-hiller]

v0.24.0 is available. Can you check if the problem still exists on your end?

[NotWorkingCode]

I get the same results on version 0.24.0

Input

Output

[fabian-hiller]

You are right. I am sorry. I will fix that.

[fabian-hiller]

v0.24.1 is available. Can you check if it works now? I will soon add unit tests for the types to prevent this from happening again.

[NotWorkingCode]

Now the behavior has changed, but it still doesn't work correctly.

In my example with nullable, the type is now always a string, and the optional parameter remains a string or undefiend

[NotWorkingCode]

I'll leave my code so you don't have to rewrite it.

https://pastebin.com/4AvtfBBy

[fabian-hiller]

Strange. It works as it should for me:

[NotWorkingCode]

Do you think it could be the version of node being used?
I use 18

[fabian-hiller]

I don't think so. I also use Node.js v18. It must be related to TypeScript (I use v5.2.2).

[NotWorkingCode]

I'm using 5.3.2

[fabian-hiller]

TypeScript v5.3.2 produces the same results in my editor. Can you clone the Valibot repo and copy and past the following into library/playground.ts and check the output type?

import * as v from './mod.ts';

export const ConfigSchema = v.object({
  logger: v.object({
    level: v.string(),
    format: v.optional(v.string(), '{icon} > {time} | {level} | {message}'),
    path: v.optional(v.nullable(v.string()), null),
  }),
});

export type Config = v.Output<typeof ConfigSchema>;

[NotWorkingCode]

On playground, I get the correct result, the same as yours

[NotWorkingCode]

I tried to build the project and use the assembled library in playground - the problem returned

Apparently, the problem is only observed in the assembled library

[fabian-hiller]

You can run cd library && pnpm build to build Valibot. After that you can use the assembled library by import * as v from './dist/index.js'; in playground.ts. There are no bugs for me here either.

[fabian-hiller]

I suspect the bug in the tsconfig.json or the TypeScript or Valibot version used by your editor or package manager.

[NotWorkingCode]

You can run cd library && pnpm build to build Valibot. After that you can use the assembled library by import * as v from './dist/index.js'; in playground.ts. There are no bugs for me here either.

I did exactly that. After building with pnpm, I imported from dist and the error returned. I showed it in my second screenshot.

[fabian-hiller]

This is strange. I don't know what to do. I reinstalled Valibot in another project and tested the code there. Everything works as it should. Since I can't reproduce it, I have no way to debug it. 😐

[NotWorkingCode]

I created the project on a completely different machine and got the same result

I use tsconfig by default

{
  "compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  }
}

My clear project:
SquadTS.zip

[Sec-ant]

I can partially reproduce this problem in a WebStorm IDE.

(You can see the type of path is string not string | undefined in my repro, the correct type should be string | null though)

But I do think this is an IDE bug (or mis-configuration, I don't use WebStorm so I don't know). Moreover, if the format type is what it is reported, then expectString(config.logger.format) should also report errors but it does not, which further suggests the IDE type hinting is somewhat problematic:

If this is an IDE bug, this shouldn't affect the build process, and I can confirm no type check errors are emitted when I use npx tsc:

So you can still build your project without issues.

And everything works correctly under VSCode.

Here is my test code:

import * as v from "valibot";

export const ConfigSchema = v.object({
  logger: v.object({
    level: v.string(),
    format: v.optional(v.string(), "{icon} > {time} | {level} | {message}"),
    path: v.optional(v.nullable(v.string()), null),
  }),
});

declare function expectString(_: string): void;

declare const config: v.Output<typeof ConfigSchema>;

expectString(config.logger.format);

[NotWorkingCode]

@Sec-ant You're damn right. I switched to VS Code myself a few hours ago and noticed that the problem was solved.
This seems to be a problem with the WebStorm static analyzer.

[NotWorkingCode]

@fabian-hiller The problem was indeed solved in version 2.24.1

I'm sorry for wasting your time.
Thank you so much for the quick fix.

[fabian-hiller]

No problem. Thanks a lot that you found this bug!