Project maintainer

[hueniverse]

We are looking for someone to take over the project and maintain it moving forward. Our team isn't currently using this which makes it hard to support.

[Marsup]

May I ask what are you using now ? Hapi-swagger ? If you switched to something else it might make sense to deprecate this one and advise on the other.

[hueniverse]

Oh sweet. I didn't know about hapi-swagger. We are currently no using anything - mainly because we don't offer third party access and we can all just read the route configuration in js directly. I am not married to lout and if something else is providing better solution, I'm happy to deprecate it. But in case people find this useful as a simpler doc generator, I'd like to find it a new owner.

[Marsup]

The offer is tempting, though I might not be the best candidate with my barely-a-week of experience on Hapi :smile:

[hueniverse]

This is more about HTML and CSS than hapi. Getting the data out of hapi is the trivial bit.

[Marsup]

Following your message on twitter, I'm still up for it if no one else is.

[hueniverse]

Sold! Do you want to take over the migration to joi 2.0 or do you want me to do it and take over from that point?

[Marsup]

That should be a good exercise for me :) I can't promise any ETA but will get on it ASAP. I guess I'll also have to support both versions in the same code base like you did, right ?

[hueniverse]

Nah, just move it to use version 2 and document it as a requirement. We will be moving hapi to 2.0 soon anyway. 1.16 is just a bridge version.

[hueniverse]

And you now have admin rights.

[Marsup]

Well I'll probably bump lout to 1.0 to avoid breaking people's projects then. Thanks for the rights.

[Marsup]

@hueniverse I've put up a new branch, sorry if the diff is a bit difficult to read because of the reformatting, I thought you might want to have a look before the feature lands in case I did a major mistake. I've managed to support both apis in the same code base so no major bump. I'll leave the branch up for review a few days unless you trust me completely and I'll merge it right away.

[Marsup]

By the way, do you want to keep control of the npm publishing or should I get maintainers rights there too ?

[hueniverse]

what's your npm handle?

[hueniverse]

I like how the first step is changing 4 spaces into 2.... :-)

Note that in v2, you should use the new describe() method. Don't access any of the _variables because that's not part of the contract.

[Marsup]

My handle is marsup as well, just lowercased.

Believe it or not, the spaces were not the 1st step actually :) If there's a strong guideline across spumko's projects I'll revert, it's just a personal preference, I'm not religious about that. The describe is something I knew and forgave along the way, and I'm sorry for that. The branch will be updated accordingly.

[Marsup]

Does hapi export the joi lib (not the types) at some point ? I don't see a clean way to get access to describe unless I require validation which is not exposed.

[hueniverse]

https://github.com/spumko/hapi/blob/master/docs/Style.md

[hueniverse]

File a bug against joi. _describe() should be describe()

[hueniverse]

And npm access added.

[Marsup]

Here's another attempt. Hopefully, got it right this time :) The diff is there: https://github.com/spumko/lout/compare/master...feature;joi_v2 Support is only for v2, as we discussed, evolving from v1 to v2 is almost nothing so I won't bother on backward compatibility.

[hueniverse]

At quick glance looks fine. @wpreul should take a look as he wrote the original code.

[Marsup]

Actually failed on something. params.constructor !== types.any can never be false. Since I don't have access to the true any, I have to do params instanceof types.any().constructor. It's ok but it seems like I would have far less troubles if I had access to the root describe of the library. I'll add tests for this case soon.

[Marsup]

Added a new route in the tests and modified the code in consequence.

[Marsup]

Another commit added, I went for a bigger change than I expected to deal with joi objects at the root. Since the root can now have properties of its own (eg. allowUnknown), I have to change the output/templates/models a bit to reflect that. It's essentially the same, but we now see the root object. I'll have to deal with arrays soon.

[hueniverse]

Should probably leave this issue alone and document further changes in new issues.

[Marsup]

I thought so as well. I'll merge this end of the week, unless @wpreul finds outstanding issues.