This works perfectly:

budo( 'src/index.js', {
    port: 3000,
    live: true,
    transform: babelify
} )

This correctly serve the file but it does not browserify and es6 the file:

budo( './src/index.js', {
    port: 3000,
    live: true,
    transform: babelify
} )

tmpdir creation and destruction should be tested more thoroughly on different platforms

Ran into some odd caching issues today where assets were not the latest as I would expect. May need to tweak ecstatic's cache time.

There seems to be a bug or then it's intended behaviour but in my current project I have shaders being compiled via glslify budo does not watch these files. So if I change my index.frag or index.vert file budo does not recompile the bundle.js.

With nodemon you can set extensions to watch for:
-e, --ext ................ extensions to look for, ie. js,jade,hbs.

for some reason simple tests are not getting source-mapped correctly.. latest browserify works fine. gotta investigate

Is there a way from the command line to call a command when the file watchers detect a change?

I want to be able to run linters when budo detects a .js file is changed - but I don't want to add another file watcher to the mix. For example:

budo -- --onchange npm run lint

Might be nice to explore different options for live reload

I'm trying to use budo with the browserify-css transform. I use the simple example taken from browserify-css.

/* app.css */
@import url("css/one.css");
@import url("css/two.css");
body {
    background-color: #fff;
}

// index.js
var css = require('./app.css');
console.log(css);

I run with the following command

budo index.js --live -- -t browserify-css

If I make a change to app.css then a reload is triggered. If I make a change to, for example, css/one.css then the log will show

{"time":"2015-09-07T21:01:01.257Z","hostname":"secret","pid":8408,"level":"debug","name":"budo","type":"change","url":"css/one.css"}

but there will be no page reload.

Is it possible to trigger a page reload for changes to css imports? If so then do I need to pass some other options to budo/browserify?

It might be handy to use this your machine internal ip instead of localhost to open the page.

https://www.npmjs.com/package/internal-ip

I am trying to think on a way that would allow budo requests to *.less,*.sass files to activate the pre-processor, run the output through auto-prefixer and render the outcome as text, directly injected into a page without the need to generate a physical file, basically the same as it does by default with javascript files.

Would that be somehow possible to achieve with budo?
The way it works is genius, but I only missing CSS pre-processors to really improve my workflow.

Ideally this would be achievable if the reload method accepted the file contents instead of its path only, like:

main.less

body {
    background: red;
    p {
        color: green;
    }
}

main.less compiled into .css and made available for rendering in-browser

app
  .watch('*.less', { interval: 300, usePolling: true })
  .live()
  .on('watch', function(type, file) {
    if (path.extname(file) === '.less') {
        less('./main.less').then(function (css) { 
            app.reload('main.less', css); //css => body { background: red; } p { color: green; }
        })
    }
  })

Thanks a lot

should probably clean this up to avoid swallowing any errors:

Currently if you're for instance running budo on desktop and trying to debug mobile live reload fails because the livereload script tries to load from localhost.

Might be good to use:
https://www.npmjs.com/package/internal-ip

And replace locahost with the internal ip of the server.

Actually, initially i was surprised why there is needed index.html when it use simple-html-index. But yea, almost. Javascript works, but it not sets the style. (lib/server.js#L172)

I think that it should also servers default css. I mean... basically I understand what it happens under the hood, without looking the code deeply. For example, if we have

 budo example/other.js:foo.js --live --dir example | garnish

It browserifies other.js to foo.js (or whatever you defined it),
mark it as "bundle"

info browserify: /foo.js 511ms (bundle)

and keep it in memory and start listening on index.html route (if we pass --dir, im not sure), then that route use simple-html-index which use that "bundle" and serves that default index, without writing the bundle and index.html to disk. But it also would be useful to have default styles endpoint. And yea, i see that we can change this behaving if we write our index.html file, but ye.

Talking about next branch.

might rename to something else

hmm.

in the vein of wzrd: mystc, knght, wrlck, dwrf, spllcrft, wtchcrft, wnd, crssbw...

other random stuff, trying to keep it short:
misty, spdstr, spnstr, spit, wzkid, wilee (as in Wile E.), watches, warpdrive, spins, serves, yumi, daikyu, kyudo, budo

I use ' node_modules/.bin/budo main.js -- -o bundle7.js ' , but cannot output anything. Can anyone help me?

Provide push state support similar to wzrd pushstate option i.e. always serve index.html for any file not found.

wzrd app.js --pushstate

With a globally installed version of [email protected]. I get the following error:

Error:
  could not find watchify/bin/args.js - unsupported watchify version

Watchify is not installed a local dependency.

V8 bug report:
https://code.google.com/p/v8/issues/detail?id=3894&q=liveedit&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Area%20Stars

may be a bug with glslify transform, or maybe budo could handle errors better. will investigate

Should budo expose a header like this to indicate where a source map exists? Running 3.0.0 doesn't seem to have Google Chrome loading the sourcemap anymore.

X-SourceMap: /path/to/file.js.map

can speed up install time with sane since fsevents uses node-gyp and isn't cached on subsequent installs. will explore

In the first version of budo it made a bit of sense to not bundle watchify as a direct dependency, since I was using npm-execspawn to spawn a local/global version.

But now it would probably make more sense to depend directly on watchify and only use that local dependency. This would clean up some code / confusion / problems with global versions.

just using this index, and it seems that when load it budo adds empty style tag. Cant realize from where and why.

<!doctype html>
<html>
<head>
  <title>foo</title>
  <meta charset="utf-8">
  <link rel="stylesheet" href="main.css">
</head>
<body>
  <script src="bundle.js"></script>
</body>
</html>

fantastic library!

I am trying to make it work inside a docker container and it detects the file change but my browser does not refreshing itself. I assume it's something to do with tiny-lr and maybe some unix sockets issue between the container and my laptop. i'll investigate as soon as possible. here is the repo to reproduce my issue
https://github.com/oren/budo-template

(i might need to pass -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix to my run command)

Hi, so I know you have taken out the --outfile option from Budo in v3.0 (curious as to why?) but is there anyway to keep passing that option to Browserify? I have tried budo app/app.js:index.js -- -t babelify -o index.js but that does not seem to work. Thanks for any insight you can provide.

Would be nice to expose a sort of programmatic API for things like gulp/grunt to just call budo() and reap some of its benefits .. will think about this.

In [email protected] you can rename the bundle like so:

budo src/index.js:static/bundle.js

This will browserify src/index.js but serve it as static/bundle.js.

But this doesn't work with multiple entries and zsh glob expansion. So a flag is needed:

budo tests/*.js other.js --serve static/bundle.js

I'm open to other names than --serve .. Maybe --rename or --dest.

A LiveReload script is included in the bare-bones index.html that is generated when no index.html exists in the directory. When there is an index.html file in the directory, that gets served instead. It would be convenient if the LiveReload script were injected into this existing index.html.

• switch to https://github.com/mikeal/getport
• decide wether to include port finding in the API or just CLI

EDIT: for now, will stick to CLI only for portfinding

When creating a custom bundler, you can pass opts to b.transform() like global: true.

This might be possible with 'global-transform' option but it is not well documented via browserify API.

Another option might be to allow a custom bundler object passed via budo API, in which case all other options are ignored.
hmm

see discssion #30

If I have a document that loads the bundle and some other dependent, non-browserified JS file:

<!doctype html>
<html>
  <head>
    <script src="static-file.js"></script>
    <script src="bundle.js"></script>
  </head>
  <body>
  </body>
</html>

I want LiveReload to pick up changes to static-file.js and reload the page. Can you think of a clever way to do this with budo?

Should support subarg syntax in CLI e.g. for transforms

Should support the following cases:

budo . | garnish
budo .:bundle.js | garnish
budo :bundle.js | garnish

Which resolves to the entry point of ./package.json with optional entry mapping for entry URL. If no package exists, use ./index.js, if that fails, throw an error.

Note: currently in v5, not passing any entries will behave a bit differently. It will not spin up any browserify instances and will make budo act like a plain http server with LiveReload.

budo | garnish

beefy uses -d by default to enable source maps... not sure if this is the way to go.

But I find myself adding it every time i'm using budo for dev

This happens when you do budo test.js with a default index.html, which uses test.js in the <script> tag.

Workaround:

budo test.js:bundle.js

or

budo test.js --serve=bundle.js

Related:
Experience-Monks/hihat#17

The use case I'm seeing is using react-router's historyLocation and developing with budo locally. It would be useful to create a custom route for unhandled requests so that refreshes don't break.

Handling "pending" state as discussed in watchify#180 to avoid getting served stale bundles or empty files. Usually this timeout is short, between 0 and 600 ms.

A proper fix might involve using watchify's programmatic API rather than spawning a child process.

Another solution for now might be to avoid serving the bundle file until it's length is not 0 (giving up after a few tries, in case the file is legitimately empty). Nope; only gets truncated after file writing begins (i.e. after 600 ms).

Other ideas?

Budo is growing into a more general-purpose tool than it was when it first started, so I'm looking to create a better UX. Some planned changes:

• add --open option which launches the browser; no need for opnr anymore
• use auto-portfinding in both CLI and API
• use auto-portfinding for live reload server #34
• include a --no-portfind or { portfind: false } option to disable it
• include API aliases for dash-case names like browserify API does
• force all browserify options to be after a full stop -- to fix #30
• explore proxying / pushstate options #45 #41
• errorify by default ?

Hi @mattdesl, and thanks a bunch for budo! I really like it 😁

I would also like to use it for work, but have a challenge. Our "API" at work is this complicated distributed mess. It's not really feasible to run all the required pieces on a laptop. So I need to "connect" to an environment to get data. My proposal is; configurable proxy paths for budo.

There are several ways to go about it, but the basics would be to configure a local path to a proxy server;

budo app.js --proxy /api:http://localhost:8080/api

Translates to; any calls to http://budo-dev-server/api should be proxied to http://localhost:8080/api

This way the proxied-to server can be any arbitrary server, and we avoid baking any knowledge about how the proxy works into budo. I have lots of requirements for my proxy, it needs to perform auth, logging etc. But all this logic can go into my localhost:8080 server allowing me to connect to my complex backend from budo 😄

How to handle syntax errors in code while bundling.

Some issues worth investigating:

• errors appear printed in console (due to this) - not bad but could be written to document.body
• with --live the error is not printed to terminal console

It might be cool if budo's routes were able to be persisted to disk. This would allow users to prototype using a live-reloading environment, and once they're happy with the results store the output to disk and deploy it to GH-pages.

Currently the following modules are available to do this:

• wayfarer - generic radix-trie router
• wayfarer-to-server - server-side wrapper for wayfarer adding HTTP method support
• wayfarer-to-fs - write wayfarer-to-server paths to disk

Usage looks like this:

const toServer = require('wayfarer-to-server')
const toFs = require('wayfarer-to-fs')
const wayfarer = require('wayfarer')

const router = toServer(wayfarer())
router.on('/', {
  get: (req, res) => fs.createReadStream(__dirname + '/index.html').pipe(res))
})

toFs(router, __dirname + '/dist', (err) => {
  if (err) throw err
})

What do you think of adding such functionality to budo?

I have a filesystem with a space in my path: /Volume/Case Sensitive/...

And when I try to use --outfile:

{ [Error: EISDIR, open '/Volumes/Case'] errno: -21, code: 'EISDIR', path: '/Volumes/Case' }

Regards,
gre

Routing to /blah.html should inject live-reload script if --live is enabled

I'm seeing a ton of lines like this in my console

{"time":"2015-07-31T21:36:54.978Z","hostname":"localhost","pid":24816,"level":"info","name":"budo","url":"/sample4.png","type":"static"}

How do I turn these off? I saw the option --no-debug but I need the source-maps. I couldn't find any mention of setting the debug level in the docs folder.

Hi !

What do you think about using getport for --live the same way you do it for the server port. It would be useful when having multiple budo instances running at the same time to have an auto live port pick from budo, for now it's either 35729 or --live-port but it won't work well if we select the same port multiple times (or if we don't select --live-port at all multiple times).

I'm currently working on a PR to add this feature (see this commit) but I have a hard time finding where the live reload <script> tag is inserted in the html, could you give me some pointers?

Thanks for your work on this cool lib, I'm using it a lot lately :)

Cheers

Eventually it would be good to pull the "core" of budo out into its own module like watchify-server or something. This would make it more useful for non-static sites, specific bundler setups, and local servers like hihat.

open to suggestions

budo app.js:bundle.js --port 3000 --verbose --live

am I doing something wrong?

Spitballing some TODOs. See the alpha branch.

• better error handling, maybe in the style of beefy (showing error in browser)
• unit tests
• testing tmp directory on Linux/Windows and other environments
• making --path option more robust, maybe rename to --dir ?
• decouple --live from budo-chrome so user has to specify explicitly if they want LiveReload in addition to script injection
• handling entry mapping for tmp outfile option so user can specify something other than bundle.js
• add option to include LiveReload in script or index.html ?
• move budo-chrome out of "core" budo module

pros:

• handle pending bundles easily #19
• programmatic API can accept objects for transforms/plugins/etc
• no need to chokidar the bundle.js file
• might simplify some code and avoid potential cross-platform woes with spawning child processes
• pretty-printing timing
• no need for temp dir

cons:

• introduces some peer dependency woes
• for e.g. maybe pending feature should be progressively enhanced so this doesn't outright break on watchify 2.x

i think this is the way to go. roadmap:

• watchify resolve algorithm (Beefy's is currently not working for me)
• handle pending so you are never served a stale/empty bundle
• remove the debounce by default (seems unnecessary in my tests) but allow user to set --delay
• change watcher to only look for HTML/CSS (no need for additional watchers) - breaking change
• add on('update') to receive bundle events for LiveReactLoad and such
• pretty-print time updates instead of using watchify's
• if no --outfile is specified, just pipe the contents directly to the request
• docs: encourage use without --outfile since there is no longer any temp file shenanigans
• remove temp dir stuff
• explore outpipe and determine whether it's the best way forward for exorcist / uglify / etc
• update demos / examples / budo-chrome / tests