browser-resolve allows you to override packages when browserifying your app.

when using beefy, these are not processed.

Hey @chrisdickinson, what're your thoughts on switching out beefy's current style of bundling to using watchify instead? There's a huge improvement in bundle speed – I've seen 30s builds go down to 100ms. The trade-off is losing custom command-line paths (i.e. --bundler), but could be substituted by pointing to a local module.

It'd probably be a good time to make the change considering you've started on a rewrite too :)

Typical scenario, you have a structure like this:

index.js
app
   index.html
   other-page.html

And you want to test the other-page.html with beefy:

beefy index.js --cwd app --index=./app/other-page.html

However, because beefy always looks for a default "index.html", this will not work unless you rename index.html to something else.

Example on the site: http://didact.us/beefy/
returns an error when opening it in the browser:

Coomand

beefy foo.js 9966

Result

listening on 9966
200    3ms      191B /index.html (generated)

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: spawn ENOENT
    at errnoException (child_process.js:980:11)
    at Process.ChildProcess._handle.onexit (child_process.js:771:34)

Is Windows supported or is this something to do with something else?
Thanks!

I have a simple file containing just an IIFE.

(function(){})()

I have the latest Beefy 0.4.5. When I run beefy main.js, I get no output from Terminal (ZSH on iTerm2, if it matters).

As you can see, if I hit http://localhost:1234, it's serving fine (when the output started), but there was no initial output until I hit the URL (no serving on http://localhost:1234/).

Because I initially expected that line, I thought Beefy was crashing somehow.

A normal call to browserify main.js produces the correct JS.

Cheers!

Instead of using the fallback index, would be great to use an existing index, if we have one. Thoughts..? Would make the whole single page app thing a lot easier.

It would be great if you could get jsx support out of the box, then beefy would be a quick tool to prototype react.js components.

Hi,

If I use beefy() programmatically and provide an empty entry_points object (I've used browserify to generate a static bundle.js to serve in production and don't want to generate it on the fly on each request) then fake_index() crashes.

This happens because the following line makes ENTRY_POINT_URL undefined:

https://github.com/chrisdickinson/beefy/blob/master/lib/server.js#L212

because entry_points is an empty object and obviously doesn't have any properties.

Now that we know why it crashes, I'm a little unsure where the problem should be fixed. Is it ok to put in a guard and set index_path to empty string? E.g. something like this:

index_path = query.p || (ENTRY_POINT_URL ? ENTRY_POINT_URL.replace(cwd, '') : '')

This would make the rendered fake html file have an empty <script> tag:

<script src="/" type="text/javascript"></script>

which is kind of odd, but at least it doesn't crash. Is there any particular reason why the fake html should even have the entry point? Just curious of the use case.

Cheers
/Magnus

Error message:

/home/lms/src/multiscreen/node_modules/beefy/lib/server.js:214
    index_path = query.p || ENTRY_POINT_URL.replace(cwd, '')
                                            ^
TypeError: Cannot call method 'replace' of undefined
    at fake_index (/home/lms/src/multiscreen/node_modules/beefy/lib/server.js:214:45)

The same beefy instance works in other browsers, including IE9, but in IE8 I get a 404 response.
Let me know if you can reproduce.

Not sure what's happening, but when I use --open it opens a new chromium-browser session with 3 tabs whose urls are:
"http://http/"
"file:///localhost"
"http://0.0.31.64/"

It works great when I manually enter localhost:8000 though! Any ideas?

idea stolen from https://github.com/shama/scriptify

e.g. maybe if you do beefy (no args) it should start a server and automatically browserify any script tags with type="text/browserify"

Can't get this to work with browserify transforms as specified in the package.json or as a -t command-line parameter beefy ./ --open -- -t reactify

In beefy 2.0.1, running with watchify 0.10.2 doesn't work. For example, in glslify-workshopper I get the following message if I run with watchify installed:

/Users/mikolalysenko/GitHub/glslify-workshopper/node_modules/beefy/lib/bundlers/watchify.js:45
      return watchifies[entryPath]()
                                  ^
TypeError: Property '/Users/mikolalysenko/GitHub/glslify-workshopper/menu/index.js' of object #<Object> is not a function
    at Object.handlePath [as command] (/Users/mikolalysenko/GitHub/glslify-workshopper/node_modules/beefy/lib/bundlers/watchify.js:45:35)
    at handle (/Users/mikolalysenko/GitHub/glslify-workshopper/node_modules/beefy/lib/handlers/bundle.js:48:27)
    at handle (/Users/mikolalysenko/GitHub/glslify-workshopper/node_modules/beefy/lib/handlers/log.js:42:5)
    at beefyMainHandler (/Users/mikolalysenko/GitHub/glslify-workshopper/node_modules/beefy/lib/create-handler.js:42:12)
    at handler (/Users/mikolalysenko/GitHub/glslify-workshopper/node_modules/beefy/index.js:77:5)
    at Server.<anonymous> (/Users/mikolalysenko/GitHub/glslify-workshopper/index.js:88:14)
    at Server.EventEmitter.emit (events.js:98:17)
    at HTTPParser.parser.onIncoming (http.js:2108:12)
    at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:121:23)
    at Socket.socket.ondata (http.js:1
npm ERR! [email protected] start: `mkdir answers; cd answers && NODE_ENV=development node ..`
npm ERR! Exit status 8
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR! This is most likely a problem with the glslify-workshopper package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     mkdir answers; cd answers && NODE_ENV=development node ..
npm ERR! You can get their info via:
npm ERR!     npm owner ls glslify-workshopper
npm ERR! There is likely additional logging output above.
npm ERR! System Darwin 13.1.0
npm ERR! command "node" "/usr/local/bin/npm" "start"
npm ERR! cwd /Users/mikolalysenko/GitHub/glslify-workshopper
npm ERR! node -v v0.10.26
npm ERR! npm -v 1.4.3
npm ERR! code ELIFECYCLE
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     /Users/mikolalysenko/GitHub/glslify-workshopper/npm-debug.log
npm ERR! not ok code 0

I think it might be better long term to pin beefy to a specific version of watchify, rather than letting this float. Even though these projects are relatively well maintained it is possible for watchify/browserify to introduce breaking changes and locking to a specific version via semantic versioning seems like a better solution going forward.

When I'm using 0.4.0, I get this as expected:

<script type="text/javascript">
/* injection code */
</script>
<script type="text/javascript" src="/bundle.js"></script>

But I've started getting this with 0.4.1:

<script type="text/javascript">
/* injection code */
</script>
<script <script type="text/javascript"type="text/javascript"  src="/bundle.js"src="/bundle.js">></script>

I think this is something going on with trumpet and @dlmanning's script-injector module, but haven't looked into it yet. If I work it out I'll send through a pull request but figured I'd give you a heads up in the meantime :)

From the OS X Terminal, you can command click a URL to open it in your default browser. This is convenient.

Can you change...

listening on 1222

...to...

serving on http://localhost:1222

...or something to that effect?

The semantic versioning strings should be updated to use the new node 0.10 "^" prefix, that way the packages will be upgraded as-needed.

See this for reference: http://www.jakobm.com/semver-in-nodejs-and-npm

Hi. I'm getting "Uncaught ReferenceError: require is not defined" when my bundle.js is loaded in browser.

Here is my application structure:

app
-js
--one.js
--two.js
--bundle.js
-index.html
node_modules
server.sh
build.sh

Here is my server.sh:
./node_modules/.bin/beefy app/js/bundle.js --cwd app --live --open --debug=false

My bundle.js doesn't seems to be converted. No exceptions in console ... Any suggestions?

PS when i'm building my bundle.js via browserfy everthing is ok:
./node_modules/.bin/browserify app/js/bundle.js | ./node_modules/.bin/uglifyjs > app/js/bundle.min.js

I install global packages in ~/npm/. npm exists in /usr/bin. Beefy seems to rely on the location of npm when looking for bundlers rather than calling which on the actual executable (e.g. watchify).

• installing global packages w/o root
• npm prefix

When I add console.log(dir[i]) in the for loop in setup-bundlers.onglobals I see that it's not looking in my ~/npm/ directory for browserify/watchify:

➜  beefy  cat ~/.npmrc 
prefix = /home/diamonds/npm
➜  beefy  which browserify
/home/diamonds/npm/bin/browserify
➜  beefy  which watchify 
/home/diamonds/npm/bin/watchify
➜  beefy  which npm
/usr/bin/npm
➜  beefy  cd -
~/treackpadello
➜  treackpadello git:(master) ✗ beefy         
>> entering setup-bundlers.onglobals
>> starting loop over dirs...
/usr/share/node-gyp
/usr/share/npm

/home/diamonds/npm/lib/node_modules/beefy/bin/beefy:13
    throw err;
          ^
Error: Could not find a suitable bundler!
    at onglobals (/home/diamonds/npm/lib/node_modules/beefy/lib/setup-bundlers.js:53:18)
    at /home/diamonds/npm/lib/node_modules/beefy/node_modules/find-global-packages/index.js:40:25
    at Object.cb [as oncomplete] (fs.js:168:19)

Looks like the live-reload functionality uses long-polling of sorts. In Firefox, this results in the loading spinner on the tab itself to always spin as if the page never fully loads.

Perhaps waiting to initiate the ajax request until after the page has finished loading would help alleviate this, and cause firefox to not assume the live reload request is part of the initial page load?

Could you please push 2.1.2 to npm? 2.1.1 seems to be latest there https://www.npmjs.com/package/beefy
(I hope to get this issue fixed 2.1.2 sass/node-sass#301 )
thanks in advance

The window.location = window.location code to trigger a page reload doesn't always work. I'm not sure what breaks it exactly, but I've been using beefy with the intel app framework and it wasn't working. I tracked down the problem to that line of code.

This change fixes it:

  es.onmessage = function(ev) {
    if(ev.data === 'reload') {
      //window.location = window.location
      window.location.reload()
    }

The docs say that specifying --cwd will run beefy as though it was running from the specified directory. However i could not get it to work like that.

My directory structure is as follows

- app
  - index.js
  - index.html
- node_modules
- package.json

if i run beefy from within the app directory i can use the following command
../node_modules/.bin/beefy index.js -- -t brfs
If i run it from the project root i need to use the following command
./node_modules/.bin/beefy --cwd app app/index.js:index.js -- -t brfs

My expectation is that i should be able to use the following command
./node_modules/.bin/beefy --cwd app index.js -- -t brfs

$ node -v
v0.10.29
$ npm list beefy
└── [email protected]

Not sure what's up, maybe an issue with watchify?

Using beefy 2.0.1 with --live sometimes doesn't trigger a reload event on file save. The odd thing is that I can open another file in the same directory and save it, and it will trigger the reload.

Has anyone else experienced this? Seems to happen all the time for me. OSX Mavericks here.

Old beefy works fine, never had an issue with reloading.

When I open the browser...

/home/jeremy/.npm-packages/lib/node_modules/beefy/node_modules/script-injector/node_modules/trumpet/index.js:87
            d.end();
              ^
TypeError: Object #<Object> has no method 'end'
    at /home/jeremy/.npm-packages/lib/node_modules/beefy/node_modules/script-injector/node_modules/trumpet/index.js:87:15
    at Array.forEach (native)
    at Trumpet.<anonymous> (/home/jeremy/.npm-packages/lib/node_modules/beefy/node_modules/script-injector/node_modules/trumpet/index.js:86:26)
    at Trumpet.g (events.js:180:16)
    at Trumpet.emit (events.js:92:17)
    at Plex.<anonymous> (/home/jeremy/.npm-packages/lib/node_modules/beefy/node_modules/script-injector/node_modules/trumpet/index.js:23:14)
    at Plex.g (events.js:180:16)
    at Plex.emit (events.js:117:20)
    at /home/jeremy/.npm-packages/lib/node_modules/beefy/node_modules/script-injector/node_modules/trumpet/node_modules/html-select/node_modules/stream-splicer/node_modules/readable-stream/lib/_stream_readable.js:934:16

something like this:

var WebSocketServer = require('ws').Server
var websocket = require('websocket-stream')
var beefy = require('beefy')
var path = require('path')

var browserifyCmd = path.join(__dirname, 'node_modules', 'browserify', 'bin', 'browserify')
var server = beefy(process.cwd(), browserifyCmd, ['test-client.js'])
var wss = new WebSocketServer({server: server})

server.listen(9966)

(doesn't work due to multiple beefy errors though)

Beefy 1.x.x CPU usage for node sitting at ~2%.
Beefy 2.0.1 puts usage at ~120%

This is on OSX 10.9.3 with Node 0.10.29.

Seems odd?

Just tested on a fresh OSX machine that was using NVM to manage multiple node versions. It seems like global installs were going into an .nvm folder.

Nothing would happen when running beefy (just quits, no errors or logs). Once browserify was installed globally, everything worked fine.

I'm on ubuntu 14.04 (Linux diamonds-ThinkPad-T530 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux) and node v0.10.25.

When I run beefy I get nothing, it just returns with code 1. I've tried reinstalling beefy as well as browserify globally with no luck.

I get no output from beefy, even with --debug, --help, etc. What can I do to debug this issue or collect more info? Also: beefy should not fail silently like this... I could probably resolve the issue on my own with better error reporting. Thanks! 😸

sudo npm install -g beefy;
npm http GET https://registry.npmjs.org/beefy
npm http 304 https://registry.npmjs.org/beefy
npm http GET https://registry.npmjs.org/beefy/-/beefy-0.5.1.tgz
npm http 404 https://registry.npmjs.org/beefy/-/beefy-0.5.1.tgz
npm ERR! fetch failed https://registry.npmjs.org/beefy/-/beefy-0.5.1.tgz
npm ERR! Error: 404 Not Found
npm ERR!     at WriteStream. (/usr/local/lib/node_modules/npm/lib/utils/fetch.js:57:12)
npm ERR!     at WriteStream.EventEmitter.emit (events.js:117:20)
npm ERR!     at fs.js:1596:14
npm ERR!     at /usr/local/lib/node_modules/npm/node_modules/graceful-fs/graceful-fs.js:103:5
npm ERR!     at Object.oncomplete (fs.js:107:15)
npm ERR! If you need help, you may report this log at:
npm ERR!     
npm ERR! or email it to:
npm ERR!     
npm ERR! not ok code 0

I like the simplicity of Beefy, but I find it hard to integrate SASS compilation into the livereload-workflow.

I tried using a custom --bundler command for tacking it along but it was super awkward.

Do you have better ideas, or am I doing it wrong?

• Also note that "best practice" of using beefy in your project is to peg browserify at a given point release in your project's package.json

I only get this error. I read other issues' fix by applying the throw err line. the CLI reports too, are no good. Can I edit some of the code to show more elaborate error reports?

Ref: eslint/eslint#593

I was banging my head around this issue for quite a while. If you serve some /folder with beefy (which has an index.html) and load it as localhost:9966/folder, the asset references inside will be recognized as relative to localhost:9966, not localhost:9966/folder. If you load the page as localhost:9966/folder/, it will work fine. Beefy needs to handle folders regardless of the slash at the end.

I don't mind that it doesn't work, but throwing the error kills beefy which requires context switching (back to the terminal to see what's up) instead of just fixing the url you're trying to hit and have it work.

for instance, if you have:

foo/bar.html

and you go to localhost/foo/bar in your browser there should be a default extension with a default of .html so if it 404s on foo/bar it will automatically try foo/bar.html

the current behavior is that beefy doesnt see a file called bar and ignores bar.html and instead serves its generated index

this is how gh-pages works as well as ecstatic

My gut instinct is to have it replace the js file with one that contains:

console.error(the_error_message)

Or something along those lines. Then I know to go look at my source and fix it, etc.

I set watchifyand 'live' to true value ,and I change the main.js file content, But the bundle.js can't' reload .I just want to live reload my bundle.js file. can anyone help ?

var beefy = require('beefy')
, http = require('http');

http.createServer(beefy({
entries: ['main.js']
, cwd: __dirname
, live: true
, quiet: false
, watchify: true
, bundler: "./node_modules/.bin/browserify"
, bundlerFlags: ['-o', 'bundle.js']
, unhandled: on404
})).listen(8124);

function on404(req, resp) {
resp.writeHead(404, {})
resp.end('sorry folks!')
}

I don't think I am doing anything wrong here -

$ cat foo.js 
var url = require('url')
document.body.innerHTML = JSON.stringify(url.parse(window.location.href))
$ beefy foo.js 
$

The server never executes.

Also can you tell me what's the difference between beefy and browservefy ? Why didn't you keep a single package ?

For some reason I have beefy in my devDependencies but not browserify. Naturally things didn't work for me after doing and npm install on a new machine. That's expected. But the error message I got was a little confusing:

listening on http://localhost:8001/
200   19ms      886B /index.html

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: spawn ENOENT
    at errnoException (child_process.js:980:11)
    at Process.ChildProcess._handle.onexit (child_process.js:771:34)
npm ERR! weird error 8
npm ERR! not ok code 0

Since this could often be a "first impression" of the beefy workflow for people it would be nice if the message was a bit more informative. In my min it would be as simple as typing out a message saying that the user needs to install browserify. I'm happy to fix this issue by adding such a message if no one objects...

if I have a `www/ folder i'd like to have a start script that does:

beefy www/demo.js

except if I wanted www/index.html to get served beefy will currently look for index.html instead.

an option to specify the base path or just parsing the beefy argument and using the folder from the entry as the base path would fix this

if you have an <path>/index.html file, and navigate to <path>, it crashed the server.

I apologize in advance for this newbie question ...

serves up static files with grace and aplomb (and also appropriate mimetypes)

How do I do this? I don't see any option for static paths. This is my set of options I'm using now...

http.createServer(beefy(
  entries: '/client-app': 'client/app.coffee'
  cwd: __dirname
  live: true
  quiet: false
  bundlerFlags: [ 
    '-o', "bundle.js"
    "-t", "coffeeify"
    "--extension", ".coffee"
  ]
)).listen 1340

This is my file structure

project/
|–– public/
|    |–– js/
|    |––  |–– index.js
|    |––  |–– bundle.js

When I'm in my project/ directory, I run the following command:
beefy js/index.js:js/bundle.js —live —open -d

Everything appears and refreshes correctly.

However, a favicon is being pulled from a completely separate directory. This favicon is not in a parent directory. It's from a parent's parent's sibling directory.

If I have a file, main.js, for example in the app folder of my project folder (the project folder is where i run beefy from) and I have my own index.html in the project folder, running beefy like this does not inject a browserified 'app/main.js' into my index.html (does not inject anything): beefy app/main.js --live
It does however inject the live-refresh script and it does inject my app script if I don't provide my own index.html. Specifying --index=index.html to beefy as a command-line option changes nothing. I have to manually add the script element to my index.html.

Hey,

I can't verify or isolate the cause right now.... but I'm guessing, based on observation, that beefy doesn't work reliably with multiple windows on the same url - does that fit with your understanding?

Right now folks need to add a script tag to their HTML to enable live reloading if they're not using the generated index files. This is in direct opposition to the (unwritten) goal of beefy -- to help for as long as possible, but then to get completely out of the way as soon as you don't need it without having to change any of your code.

We could use trumpet to achieve this.

• Beefy version: 2.1.1
• Node version: 0.10.28

Browserify applies transforms in the order that they're specified, but beefy appears not to do the same. You should be able to reproduce this as follows:

beefy({
  bundlerFlags: ['-t', '[', 'envify', '--test', './another.js', ']', '-t', 'fresh-require']
})

var fresh = require('fresh-require')

console.log(fresh(process.env.test))

The above should substitute process.env.test with './another.js' before reaching fresh-require, but instead fresh-require's transform runs first regardless of the order they're specified.

The README says you need to add a script tag pointed to /-/live-reload.js but Beefy seems to inject this for you, even in the case of a custom HTML file.