Better ways to determine Hook source code entry point?

[joshgillies]

Basically I came across this: https://github.com/bigcompany/hook.io/blob/master/lib/resources/hook/fetchHookSourceCodeFromGithub.js#L72

And now wonder whether it could be an option to employ a more Node-like solution to Hook entry point resolution?

With the goal to not breaking all existing Hooks we treat the "assume first file is the source code" rule as the fallback case for code resolution, relying on the existence of a package.json, or index.js as the first port of call?

Would something like this be achievable with the GitHub Gist API?

The motivation for this is to open up the ability to more adequately develop, test and deploy Hooks in a similar fashion to how I currently develop modules.

[Marak]

I think the right approach might be moving away from reliance on the Gist API and using it as an optional place to store hook source code.

Could you explain your ideal development workflow a bit? I've been working on a few changes locally to try and improve general workflow.

I haven't added explicit support for package.json anywhere, but it would be relatively easy to add. The platform now auto-installs missing dependencies at run-time, but having an explicit package definition wouldn't be a bad thing.

[joshgillies]

I have to admit, while Gists are a fine place for hosting a Hooks source, I'd be all for alternatives. Although, I do wonder where else would be appropriate. Is there an issue for tracking this currently?

Personally I see Hooks lending themselves nicely toward npm style module development. Ideally the Hook initialisation process would be driven entirely by tooling of some description, and would include a standard source layout, with testing/mocks in place.

Obviously the benefit here would be offline testing/development, but would also lead toward some form of continuous integration.

If a driving idea behind hook.io is to offer a collection of general purpose end points, it would be great to be able to get insights into how well tested a Hook is, who maintains it, etc.

These are rough ideas at present and I welcome feedback/criticism. Potentially related to #63 as a best practice discussion for Hook development?

[Marak]

Related issues: #95, #63, #17

Thanks for the feedback. I agree with what you are saying.

I already have a good start on the hook cli tool. We can use this to bootstrap local development and provide scaffolding. We can also have the web app perform a gui wizard.

These are just the tools. We'll also need the standard / best practices defined.

Do you have a wish list for features or specifications of services?

I'm not trying to re-invent too much here. Using package.json format might suffice to describe the manifest of a service. We could create an additional manifest format, I'm not sure.

[joshgillies]

I've spent a little time thinking about the source code hosting and hook entry point resolution and I still can't think of anything better than a package.json to describe that. Seems like the most natural for for a hook. I could be wrong of course! But this leads me to another idea I had with regards to hosting of hooks source code. Could npm actually be a source of code hosting for hooks also? In that when creating a hook you could specify a valid package from npm and have it deployed as a hook?

[Marak]

package.json support seems like the right idea.

Moving forward with the local development tools I'll start to integrate package.json.

[Marak]

This has been somewhat resolved with the release of https://github.com/stackvana/microcule

microcule has package.json support and the latest version of hook.io surfaces some of these entry points. Upcoming deployment will have custom main entry points for Gist and Github sources ( using microcule plugins ).

Will keep the issue open, but hoping some of the discussion moves to microcule related issues.