lib/index.js makes wrong use of HauteCuture.using() by default and hence 'npm start|test' don't work

[dcominottim]

The line

await HauteCouture.using()(server, options);

results in

Error: "schwifty" is not a method on the passed server.

when trying to npm start or npm test.

The fix is to replace that call with

await HauteCouture.using();

as per hapipal-realworld-example-app.

[devinivy]

Hey there. I don't think this is an issue, and you may have some misuse of haute-couture in your project if you've made this change.

In the realworld app here it reads:

exports.plugin = {
    pkg: Package,
    register: HauteCouture.using()
};

Whereas in the boilerplate here it reads:

exports.plugin = {
    pkg: Package,
    register: async (server, options) => {

        // Custom plugin code can go here

        await HauteCouture.using()(server, options);
    }
};

The difference is that the boilerplate leaves room for some custom code by default. HauteCouture.using() returns a function with the signature async (server, options) => {}, which is precisely the signature of a hapi plugin's register() function. So both of those usages above are valid/correct!

Your error Error: "schwifty" is not a method on the passed server. is most likely because you registered some models in lib/models/, but the schwifty plugin (which provides the method server.schwifty() used by haute-couture to register models) was not registered to the server yet. The fix is to install schwifty npm install schwifty and ensure it is registered by your plugin, usually in a pal project by creating the file lib/plugins/schwifty.js. The boilerplate also has a "flavor" for objection that will set all of this up correctly for you! Here's a link to that flavor: https://github.com/hapipal/boilerplate#objection-orm

[dcominottim]

Thanks for the answer!

I'll check the registration part, but since I used hpal to create everything (not only the project, but also the models) I believe there's still room for substantial improvements to it. It seems fair to ask,

Why does hpal leave me with a broken project after I create one and just add a model right away, all via hpalitself?

Models are a pretty core concept to hapipal the way it is today -- it's even one of the flashlights of the website's main page.

After your explanation, I think the boilerplate itself is fine (especially since it's got a flavor for objection) but hpal might use some help. I feel confident other new users will bang their heads against this for a while during their first experience with hapipal.

Perhaps an alternative approach would be adding the schwifty module and all related registration by default, or at least as a question/parameter during project creation with hpal? It seems unlikely to me that, for someone using hapipal, schwifty models wouldn't be present in >half the projects. But even if I were wrong about that, adding the plugin and related registration by default seems like a very sane thing to do -- and if there's a fear about bloat in the defaults, I'm confident it should at least be an option during project creation.

[devinivy]

Noted! Thank you for the honest feedback. Perhaps hpal new could offer to the user to install a flavor for them, and help educate the user a bit.

One reason that the experience isn't very integrated is that all the hapi pal modules are decoupled and optional. The behavior of hpal make is even customizable based on the user's .hc.js file (the plugin's haute-couture "manifest"). For example, a user might choose to use mongoose and mongodb rather than objection and SQL, and their model/ files might look totally different and have their own dependencies aside from schwifty.

In the meantime, I have logged a feature request and discussion here https://github.com/hapipal/hpal/issues/43