bosco
bosco copied to clipboard
tes
Bosco returns different build termination messages from time to time
While running bosco cdn -v from app-resource, the build complete message is for the wrong project:
It's because the finished callback is being called more than once due to the text being found more than once in the output.
When we switched to the watch looking at the stdout line by line we definitely made this area of the code really complex and it doesn't do what we expect it to in its current form.
It needs a fresh pair of eyes.
Ok, this is working much better for me, I just ignore the weird messages, but this makes it confusing.
Have you got any high level idea on how to handle this in a more reliable way? We could just execute the Watch and pipe it to stdout without trying to be clever about it. We should just restart the watch if it exits.
Not really, if we just pipe it out it will interleave with all the other stdout. There is probably a simple solution but I can't see it right now.
I mean, we should pipe it out only on verbose. Otherwise we just say that the watch command was executed, or was executed again if it failed.
We are doing this already, except that now we say when the watch was finished too. We could make that optional.
If you aren't piping it out, how do you know when it is 'finished' and hence you can load your page? It was the primary reason for the readyText - so you could output when build was done and let user know.
Let's think of use cases:
- To run a service, I will do 'bosco cdn' in the folder and no watch will be executed.
- To develop I will be running 'bosco cdn -vw' and I will have the output from webpack to tell me a lot of interesting things, that for me is much more useful than the bosco "finished" message.
I need to keep an eye on the bundle size and such.
I'd be fine with just making all watches verbose and get rid of readyText entirely - the chance you are watching multiple projects and it interleaves is probably an edge case.
Interestingly, now that bosco always serves assets from disk, you could probably just use bosco cdn all the time and never have bosco run the watch command, and then run your local npm run watch (or whatever) in the service you are actively developing. It should all flow through.
Interesting... To run an app I do:
- Terminal 1: To get al dependencies running:
bosco run -d. I wait for it to finish - Terminal 1: To get the app in development mode:
yarn dev - Terminal 2: To get the cdn running:
bosco cdn -w
With your proposed change I would need to get a third terminal for the yarn watch-assets command.
Would it be possible to run the CDN as a dependency via bosco run -d?
What do you think?
The build output parsing isn't great, one example: app-resource watches sass and js, but has different "finished" text for them, so it only really knows when the js build is finished. I think making cdn dumber and just running the watch manually is probably a good idea. Ideally we'd be running a webpack dev server and getting live reload somehow through that as well, right?
👍👍👍👍 Dumb CDN + hot reload via webpack... but we cannot currently do it because of how assets are served I believe?
What would we need to change to enable hot reload? I never implemented it yet.
@geophree this would be a good one to explore re. if we can re-think the bundling to operate in a way that is:
a) backward compatible with existing bosco-service.json b) backward compatible with syntax of cx-bundles / cx-library c) backward compatible with projects not using webpack.
I have some ideas, e.g. using webpack programatically (e.g. so each service could serve its assets on a different port?) - instead of via a npm build script - but not sure how feasible that is.