max-mapper / wzrd Goto Github PK

Super minimal browserify development server

JavaScript 100.00%

wzrd's Introduction

wzrd

Super minimal browserify development server. Inspired by beefy but with less magic

installation

npm install wzrd -g

note that you must have a copy of browserify installed as well. It can be either local (preferred) or global.

npm install browserify --save

usage

wzrd app.js

This will start a local development server (default of localhost:9966) that serves all files in the current folder with the exception of app.js, which will be browserified instead. wzrd will spawn the command browserify app.js and send the output bundle back to the client.

If no index.html is present in the directory you run wzrd in, one will be generated for you that has a <script src='app.js'></script> in it.

mappings

You can also specify a mapping:

wzrd app.js:bundle.js

This means if a request to the server comes in for bundle.js, wzrd will run the command browserify app.js and serve that.

multiple entries

wzrd app.js:bundle.js foo.js:bar.js baz.js

https

wzrd app.js --https

this will start a local https server (by default https://localhost:4443) and generate a self signed SSL certificate. You will get a certificate error in your browser, but if you ignore the error the app should load.

passing extra args to browserify

wzrd app.js -- -t brfs

anything after -- will get passed directly to browserify as arguments. so the example above would spawn the command browserify app.js -t brfs

pushstate server support

wzrd app.js --pushstate

if you want to leverage the html5 pushstate and support natural urls in your frontend application you can use the --pushstate flag. This flag will instruct the wzrd server to always return index.html for any file not found request from your server.

wzrd's People

Contributors

Stargazers

Watchers

Forkers

zeke mafintosh mattdesl kenjispecial twilson63 emilbayes arjen-smit nichoth jan-swiecki f-u-c-k-u-p xqk jimkang bliotti therakeshpurohit

wzrd's Issues

Feature Proposal: --pushstate

Building SPA's, I often have the need to re-send the index.html page for other routes to leverage pushstate in the SPA. I would like to add a cli option --pushstate that would enable wzrd to resend the index.html every time a request that could not be handled by ecstatic or browserify.

For example,

/widgets/1234

would render index.html instead of File Not Found if I were to start the server using:

wzrd app.js --pushstate

I will be happy to submit a pull request if others would like this feature.

Thanks

Tom

Undocumented `--path` option

While poking around the source I saw the --path option. It's really handy, so it's a shame it isn't documented :)

Extra features

I have three features I miss from Beefy:

auto portfinding instead of erroring out if 9966 is taken
an --open command to launch the URL in your browser
a --dir to set the base for the entries (from path) and the serving directory (i.e. for image paths)

I've already implemented these in my own little tool. Basically wondering whether you'd be interested in having these PR'd to wzrd CLI (but not the API itself). Or, whether you'd prefer these things to just go in another module.

ndjson

Making a little wrapper on top of wzrd API for project-specific needs, and trying to get pretty-printing going with ndjson.

It seems like it's not as easy as hooking into process.stdin/stdout since we're dealing with a child process. Or am I missing the obvious?

DeprecationWarning causing 500 Internal Server Error in wzrd

All output on stderr causes a 500 Internal Server Error:

  proc.stderr.pipe(concat(function error(err) {
    console.log(err);
    if (!err.length) return
    endLog()
    process.stderr.write(err.toString())
    res.statusCode = 500

This includes the DeprecationWarning: 'GLOBAL' is deprecated, use 'global' warning added in Node.js v6: nodejs/node#1838, triggered by cwise-parser

Works with beefy (no server error)

feature request: show network ip's on server started

As I often work on different networks I find myself having to look up my IP address so I can share it with coworkers and/or other devices. It would make my life a lot easier if wzrd could output all the IPv4 addresses on startup.

This would look something like this:

server started at:
http://127.0.0.1:9966
http://10.0.0.26:9966
http://192.168.0.2:9966

Node has native support for retrieving this information so it would not require additional dependencies. If you like this idea I'll start working on a PR so this feature can be added.

site is down

scripts are inaccessible

once you are back up we will make local copies of the scripts

`--pushstate` only works with generated index.html

Really enjoying wzrd for quick prototyping! However --pushstate does not work when I have my own index.html. The bug is because you do check if a index.html file exists, but if push state is enabled you still try to serve the "missed" path: index.js#L33.

I'm not sure what the best solution is. ecstatic parses req.url, but doing something like overwriting req.url feels dirty...

source maps no longer working ?

This is strange; I just noticed it today and it's affecting budo as well as some other unrelated tools I'm exploring.

With latest wzrd and browserify installed globally:

wzrd index.js -- -d

However, source maps aren't working (try a file with a debugger, you see the browserify prelude). Yet running browserify index.js > bundle.js and opening it with a basic http-server seems to get the source maps correctly.

I'll poke around and send a PR if I come up with anything.

Can use two mappings?! sometimes?

I thought I was crazy, but reading the output, when I try the following, index.js looks like it's being served statically, and the mapped one is being browserified:

$ wzrd index.js streamoji.js:br-mo.js
server started at http://localhost:9966
{"url":"/bundle.js","type":"static","time":"2016-06-23T03:13:27.090Z"}
{"url":"/br-mo.js","type":"bundle","command":"browserify streamoji.js","elapsed":"1028ms","time":"2016-06-23T03:13:28.132Z"}

and in this case bundle.js is unusable in the browser because it's not browserified

then this

$ wzrd index.js:bundle.js streamoji.js:br-mo.js
server started at http://localhost:9966
{"url":"/bundle.js","type":"bundle","command":"browserify index.js","elapsed":"594ms","time":"2016-06-23T03:17:47.171Z"}
{"url":"/br-mo.js","type":"bundle","command":"browserify streamoji.js","elapsed":"1308ms","time":"2016-06-23T03:17:47.893Z"}

bundles both, but only sometimes. If I were running multiple simultaneous wzrds at the same time with background jobs in the shell could that create this behavior? I don't see any fanciness going on in the wzrd source.