Subscribe to broccoli builds (watcher) from Brocfile#180
Subscribe to broccoli builds (watcher) from Brocfile#180joefiorini wants to merge 1 commit intomasterfrom
Conversation
lib/adapters/broccoli/server.js
Outdated
There was a problem hiding this comment.
I think the Travis failure is do to a missing semicolon here.
There was a problem hiding this comment.
make sure to subscribe to error as well, something like:
.on('error', function(error) {
console.log(chalk.red(error.message), error.stack);
});
|
Wow, apparently I'm worthless without JSHint. Had it disabled in my editor and missed a ton of little things. All fixed up now, @stefanpenner this look good? |
lib/adapters/broccoli/build.js
Outdated
There was a problem hiding this comment.
unrelated to your commit, but we should denodify once at the top
|
so i like everything, but the actual symlinking. I really think the happy path is proxing. @joliss I would love your input. |
There was a problem hiding this comment.
The denodeify above presumably breaks this .limit setting.
There was a problem hiding this comment.
https://github.com/tildeio/rsvp.js/blob/master/lib/rsvp/node.js#L190 maybe not? (I'm not sure though)
|
Yes, copying stuff into an app's As for proxying, my worry is that you always need an internal unused port between the app and Broccoli, so we have a failure point, but it still seems reasonable in general. My sense is that tighter integration with the backend might generally be best - through a middleware or so, similar to how Sprockets works in Rails - but it may not be feasible to do for every backend in the world. </general-thoughts> |
|
I must be naive, why is symlinking or copying a bad idea? -- On March 28, 2014 at 3:32:48 PM, Jo Liss (notifications@github.com) wrote: Yes, copying stuff into an apps public dir seems like too brittle a strategy. As for proxying, my worry is that you need an internal unused port between the app and Broccoli, but it still seems reasonable in general. My sense is that tighter integration with the backend might generally be best - through a middleware or so, similar to how Sprockets works in Rails - but it may not be feasible to do for every backend in the world. — |
|
It just doesn't feel right to me. I may be wrong though. |
There was a problem hiding this comment.
we should just use an event emitter c/d ?
|
Thought about that, just didn't like the API it provides. Probably being too picky. I can change it. |
|
I'm finding myself coming around to the idea of using a proxy. If I get some time today I'll try an alternative approach with a proxy instead of this. If it works and seems good we'll close this one and go with that. Cool? |
|
@joefiorini sounds good. I am a advocate of the proxy idea. |
|
Killing this now. The proxy solution is much better. What was I thinking? ❓ |
5 participants
This allows server-side integration of ember-cli by symlinking or copying the final built tmp dir to a public folder in the server-side app. I'm thinking I may eventually pull this out into its own module as a broccoli plugin, but for now I think it makes sense in here. @stefanpenner are you cool with me pulling this in?