fix: fix the issue when 'false' convert to boolean always true

[leepood]

#306

[saulotoledo]

@leepood, could you please rebase with the current develop and address the changes requested here?

[saulotoledo]

yes/no is a bit too much. I recommend to remove them.

Please also remove the {}s, the rest of the code does not have them for single line if statements.

We also need some tests.

[saulotoledo]

You may check the tests from this PR if you need ideas.

[NoNameProvided]

I vote against having this in class-transformer as this is out of scope for this project. In JSON a boolean value looks like this: { propA: false, propB: true } trying to convert the string 'false' to true is the valid behavior because Boolean('false') is true. We should not try to figure out of the intent of the user just try to "blindly" convert the received value to the target type.

Checking whether the received value is valid or not is task for class-validator not class-transformer.

[NoNameProvided]

This issue is somewhat related to #363.

[dsbert]

@NoNameProvided If I'm transforming query parameters into a class, which are all string values, I would not expect ?print=false to transform to { print: true }. And if this behavior is intended, that's a huge foot-gun, particularly when using enableImplicitConversion: true.

The documentation has several references to parsing values from strings. For example
https://github.com/typestack/class-transformer#%D1%81onverting-date-strings-into-date-objects

Sometimes you have a Date in your plain javascript object received in a string format. And you want to create a real javascript Date object from it. You can do it simply by passing a Date object to the @type decorator:

Note, that dates will be converted to strings when you'll try to convert class object to plain object.

Same technique can be used with Number, String, Boolean primitive types when you want to convert your values into these types.

So if the answer is, "this is not how it should work", then how it should work needs to be clarified with an explicit example. Right now, I'm not sure I understand why transforming a string to a boolean is the responsibility of the validator library and not the transformer library.

[NoNameProvided]

The referenced documentation is valid, because

• Number('24') == 24
• new Date('2020-07-29T18:55:18.011Z') intsanceof Date == true
• String('a') == 'a'
• Boolean('x') == true

The transformer library must does not know anything about the content of the received payload. It should just try to convert it to the desired target type.

For your scenario a possible workaround can be to send empty query params ?myParam, depending on the library you use it will be undefined or '' both of those values converts to false.

However, I understand your scenario and I agree this is not a good approach to tackle this problem. Currently, the only solution I see is to add a flag that enables this conversion, however this is the scenario I am trying to avoid.

We will clean up a repo a little bit and will return to this issue and figure out how to go forward.

[NoNameProvided]

This won't be the accepted approach. The solution will be a decorator based approach defined here: #550.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.