wraithgar / moonboots_hapi Goto Github PK

View Code? Open in Web Editor NEW

9.0 9.0 12.0 94 KB

Hapi plugin for moonboots

JavaScript 99.75% CSS 0.09% HTML 0.17%

moonboots_hapi's People

Contributors

Stargazers

Watchers

Forkers

petreboy14 henrikjoreteg latentflip nlf joshua-mcginnis fstoerkle secobarbital achingbrain geek rluiten chabou gdibble

moonboots_hapi's Issues

Throw errors on unexpected config items

htmlContext is an option now

That means that moonboots-hapi could take a template argument.

Serve static files?

I apologize for filing an issue about this, but I have... well, I haven't quite groked where all of these parts (&.js, Hapi, and Moonboots) fit together yet.

My question ought to be pretty simple: I have a set of JSON files stored under /public, but whenever my app requests them, it gets back the Moonboots bootstrap html. (the <!DOCTYPE html><style><script> thing.)

How can I return the actual files from under /public?

Test coverage for labels and multiconfig

Need to use both in a test so we can always make sure they play nicely together.

Document new things

hapi config can have a handler and bind options now.

support different hapi config for multiple moonboots configs

Major version breaking changes

Considering these:

allow at least pre and maybe handler config for all 3 routes
description, notes, tags override for all 3 routes

Prepopulate hash or make context bidirectional

for production mode

Configureable prefix

The prefix defaults to / right now but what if we want it to be somewhere else, specifically not a url local to the server (for instance if we have an automatic cdn configured for our server)

Is there interest in being a bit more windows platform smoothness ?

Firstly this is a nice little example project thank you.

On windows platform make is not something you can just depend on being available it can be non trivial to get one going if you have no prior experience with it. To lower the bar for windows platform it is very little effort to remove make as a dependency completely as what it is doing in this project is trivial.

I can create a pull request if you would like.

Hapi 8 compatibility

Is there a way to get this module to work with Hapi 8?

The example from the readme has this:

server.pack.require({moonboots_hapi: config}, function (er) {
    server.start();
});

..but I don't think server.pack exists any more. I got a bit further with:

server.register({register:require('moonboots_hapi'), options:config}, function (er) {
    ...
});

..but must have missed something as although the server started up without error, hitting the app page left me with a blank screen.

Test for development mode

Make sure the things in development mode are there and only in development mode (cache stuff mostly)

Switch to lab for tests?

omit handler if hapi config has handler

moonboots dependency is ^3.0.0?

why not ^4.0.2

Update to hapi 2.0

Branch existing to legacy branch for now, update code to work in hapi 2.0. Party.

App path defines defaults

Now that we can have multiple moonboots instances, it would help to let the app path define the default routes for the css and js, that way one can once again rely on defaults if they were so inclined.

Handlers need access to moonboots app

Currently if you pass a handler into the config it does not have access to the currently scoped moonboots app initialized. Probably could/should or at least document how to get it from there?

add description/tags/notes to route configs

Support Hapi 8.x

moonbots-hapi does not support the most recent Hapi 8.1.0 version

Graceful errors

If we're in development mode how about writing errors to the document instead of logging it, much like how original moonboots did in express?

optional index param on getMoonBootsApps

This could probably use some attention

css/js building as /{clientPath*}.ext

noticed this viewing page-source when running server on Mac OSX or Windows:

<!DOCTYPE html>
<link href="/{clientPath*}.css" rel="stylesheet" type="text/css">
<script src="/{clientPath*}.js"></script>

when running locally, file names above clickable/viewable and include compiled js or css (but clearly the file names are erroneous.)
pages viewable locally, but chokes in an Azure deployment.

Handling browserify errors in production

I'm not sure if this is a) a moonboots or a moonboots_hapi issue or b) only happens in production, but:

On andyet-platform we had an issue where a module was missing, so browserify build was failing (caused by missing dependencies in package.json effectively). This meant that both the hash in the filename, and the browserify output itself, was being inserted as "undefined".

As i understand it, in development this type of situation renders an error to the browser by inserting it into the JS output, but we presumably don't want to do that in prod. So it seems like this should basically be a hard-exception to me on the server, as if we can't render the js source, we have no app. Thoughts?