PropTypes defaults lost when shimmed

[adrian-marcelo-gallardo]

Hello!, I'm using this library to add proptypes to a library of componentes.
Then, I'm building those components as a library (using vue-cli) and adding the option in webpack to replace VueTypes for the shim version.
Then, I'm using that generated library on other Vue application. The problem is that when that application runs, default values aren't applied, and this is causing huge error because function handlers are undefined and application crashes..

I don't know why is this happening, because when I look at the generated code of the library (the one that I'm building with vue-cli) I can see there is the prop types definition using shim object to define the defaults, and using chrome debugger I can see that the values that shim is applying are valid; BUT, when adding a console.log on my components created hook my default values are undefined.

If I remove the option in webpack to shim the library, then it works OK! (console.log on my component's hook is now defined)

Do you have any idea why might this be happening? I would really like to understand why is this problem happening

Thanks a lot in advance!

[adrian-marcelo-gallardo]

Well, I keep debugging a little more and found that the object describing propTypes is not the same when using shim and when don't.
Without shim, the propType object has a type: Function;
With shim it doesn't have a type defined, and the validator prop is an empty function..

I think this is the problem... as the default value never validates to true, then Vue it's not assigning the default value..

Why is the response object from shim SO different to the one without? is not the purpose to be the same output but with less code? Or I am misunderstanding the purpose of the shim functionality?

Thanks again, I'll wait for you response to see how can I proceed

[dwightjack]

Hi,

Vue type validation should be bypassed when vue is used in production mode. This is why both type and validator properties are empty. On the other side default should be kept unchanged. Right know I cannot check it out, but I will check it as soon as possible and report back to you.

[adrian-marcelo-gallardo]

Thanks for your help, I'll be waiting for you input!
So far, I believe to avoid loosing the default value on runtime, the validator function that it's currently assigned by shim should return true.

[dwightjack]

Hi,

I think you're right. The issue arises with some type or props (like Function) that get special treatment in prop validation. The shim don't set the type property in the prop so sometimes it breaks.
I don't think the validator function is involved since it's totally bypassed in production (see https://github.com./vuejs/vue/blob/59860b0a756526f37468655598c68d119f0e74bd/src/core/util/props.js#L55).

I've published a 1.5.1 version under the @next flag with correct types. This should solve your problems. You can try it out with:

npm install vue-types@next

Let me know if it works for you.

[adrian-marcelo-gallardo]

Hello again!, first of all, thank you very much for your quick reply; I've checked all the code you pushed today and that is amazing!!

Bad news, although, is I've checked with this new version and the problems are still there. I think adding the type is a huge win, but I'm still getting awful messages on the console and, what it's worst, that is preventing some default values from being assigned, causing the application to crush..

As I've suggested, the problem seems to be with the validator prop that's still being assigned, as it is always an "empty" function (like () => {}) and that is interpreted by Vue as something that is invalid.. If you could simple change that default validator to () => true it should prevent errors form happening...

I'm thinking I'm seeing these problems because, as I mentioned before, I'm using VueTypes on a components' library built for production, BUT I'm getting those error messages while running the web app (which is using the components' library) in development mode. So, that is causing the validators to be run preventing default values from being assigned.

I think this might be something that could potentially happen to anyone else working on an npm library.

[dwightjack]

Hi,

Ok maybe I got where part of the problem is: you built the library for production, but you're using that library in a development environment.

I think you should use the source (or a bundler compatible version) of your library. This way you'd set the production or development environment in the final app.

That said I agree that setting the shim validator to true won't hurt.
I will ping you when I've published an updated version

[dwightjack]

@adrian-marcelo-gallardo I published v1.5.2 Let me know if it works 😄

[adrian-marcelo-gallardo]

Hey, I'm not seeing errors anymore, so I believe that did the trick!! :)

Thank you very much for your HUGE help!

[dwightjack]

Cool!

I've published a stable release as v1.5.3.

I'm closing the issue for now. Feel free to reopen it if any other issue arises.
Thank you for your contribution and sorry for the issue.