Joi Peer Dependency??

[WesTyler]

I somehow overlooked the fact that Joi v10 was added as a peerDep. Is that needed since Joi is a direct dependency?

[lamchakchan]

Looks like I added it, Let's remove it.

[WesTyler]

Were there specific reasons you added it as a peer? I don't want to discount them out of hand just because I didn't think of them. :P

[lamchakchan]

I think it makes sense to put the onus on the user to install the right joi at the top level. What happens if the user sends in a schema object from different version of joi into felicity which then processes it with joi@10. Because there is a tight dependency between input data and the felicity internals, it should be appropriate to push up that install requirement upstack.

The scenario I described is different from saying using different version of lodash every package since each package are tightly coupled to the behavior of the lodash version installed and tested.

[lamchakchan]

@WesTyler after more thought, we can still remove peerDependency if we do a schema version check which I think joi now supports. But naturally, I believe in less code and utilizing the npm ecosystem where applicable.

[WesTyler]

No no, I agree with this.

Because there is a tight dependency between input data and the felicity internals, it should be appropriate to push up that install requirement upstack.

Let's keep it instead of introducing the Joi version checking code. We can always revisit if the peerDep messes people up. Thanks for chatting about it.

[lamchakchan]

@WesTyler we are going to need to migrate joi from dependencies to devDependencies

[WesTyler]

@lamchakchan err, why's that? We are directly using Joi in the Felicity src.

[lamchakchan]

You're right, I keep forgetting we are because of the describe and validate