Support e.g. Hapi about sapper HOT 4 CLOSED

I'd like to write and maintain a hapi plugin. This would be a great fit. I've used hapi extensively and written many plugins in the past. The only catch is I haven't actively written code for about 4 years. My thought is that this might be a well-scoped first project to get back into coding. The JavaScript ecosystem sure does move fast...

Here are some thoughts/notes, but please keep in mind that I have just begun familiarizing myself with the svelte and sapper code bases. Correct me if I'm wrong on any front and I'd appreciate links to any contributor resources (docs, etc).

Routing
At a high level it appears that the Sapper routing approach is very focused on how the express router works. That's totally fine, but will present challenges on integrating with other frameworks like hapi.

The first challenge is that hapi doesn't support regex patterns in route paths. This would be against the design principals of hapi (source) so I don't see it changing. Sapper supports regexes in routes, which means that the generated manifest-client and manifest-server files expose a regex as the pattern for a page/server_route.

The hapi family of projects includes the hapi/call router. It doesn't support regexes in the route path. It does support:

• exact match parameters
• optional parameters
• multi-segment parameters
• catch-all parameters

Not supporting regexes allows call to sort routes and detect conflicts.

A hapi plugin could be made, but would require bypassing its fairly robust routing capability. I think it would be possible to hack something together to work with server routes, since you can just export a hapi route, but on the page route side of things it would be a bit more difficult. Maybe we could export a property there as a short term solution that can define the actual route path to use for hapi?

Not sure how to tackle this one, but would love to hear your thoughts.

Developer Experience
As Sapper currently stands I think there would be changes to DX due to how the express API is currently surfaced in Sapper server routes. It wouldn't be that bad in the code itself, but the docs are currently focused on the express-style of server route. Just something to think about. Having server and page routes implement a logical interface by exporting a specific route pattern property would be the easiest way to make things work for any router today. The downside of this would obviously be the fact that route pattern info is currently contained in the file name, which results in duplicate info that could introduce confusion. The benefit would be that plugins can read from the exported variable whatever is needed to work. The server routes can export whatever style of handler the server router on the other side expects

Maintainability
I think it would be wise to split both the express and (hopeful) hapi middleware out into separate projects. Doing so would force some modularity in sapper on the routing side of things.

Another benefit of splitting out middleware/plugins is that the projects these middleware/plugins are targeting typically have their own style guidelines that are very different than sapper. IMO it would make more sense to follow the style guidelines of those communities in this scenario. This would increase the chance of adoption on the other side (ex: hapi) and maintenance/contributions from those communities for plugins targeting their project(s).

from sapper.

TLDR: Regexes and routing are the areas of friction here. I think the shortest path to a hapi integration today would be to require both the page and server route files to export a hapi-style route pattern property that can then be used in the plugin. This is clearly not a good path forward, but would at least make it possible to use the (awesome) sapper with hapi.

from sapper.

@wtcross I would love you to write a Hapi alternative to Polka/Express (sorry Luke).

I'm Hapi... to help you out where I can with this.

from sapper.

Any update on this one??

from sapper.