search

mattdesl / budo

:clapper: a dev server for rapid prototyping
MIT License
2.18k stars 106 forks source link

CSS Live reload stopped working with budo 10 #231

Open dbrgn opened 6 years ago

dbrgn commented 6 years ago

Hi. We're using budo for http://github.com/threema-ch/threema-web. When upgrading from budo 9 to 11, CSS live reloading stopped working. I tested a bit with different versions, and 10.0 was the first version that broke live reload for me.

This is how we invoke budo:

budo src/app.ts:dist/app.js \
    -d . -d public -d src \
    --live \
    -- -d -p tsify -t [ babelify --presets [ es2015 ] --extensions .ts ]

When starting the server, the following is logged to the terminal:

[server] [0000] info  Server running at http://192.168.11.120:9966/ (connect)
[server] [0000] info  LiveReload running

I can see that the live reload WebSocket is opened. In the Chrome inspector I can also see that every time I change a CSS file, I get a new message:

screenshot

However, no reloading takes place.

This is what the WS messages looked like with Budo 9:

screenshot

Any ideas what the reason could be?

I wonder whether the problem could be that the /public/ prefix is added as prefix, but I include the CSS files without that prefix in my HTML file (which works because of the -d public argument).

mattdesl commented 6 years ago

Is there any way I can reproduce this on my end?

dbrgn commented 6 years ago

@mattdesl yes!

git clone https://github.com/threema-ch/threema-web
cd threema-web
sed -i 's/"budo": "^9"/"budo": "^11"/' package.json
npm install
npm run devserver

Then open http://localhost:9966/ in your browser and edit/save a SCSS file in src/sass (e.g. removing #background-image in src/sass/layout/_main.scss).

Does that help?

mattdesl commented 6 years ago

Thanks. Here is a simple fix for you:

Use -d public before -d ., so for example:

budo src/app.ts:dist/app.js -d public -d . -d src --live ...

The reason is a bit complex, and it's definitely a bug or issue with budo, but I'm not sure yet how to solve it cleanly. Here's what's happening:

When a file, like ./public/css/app.css is changed, we have to turn that into a URL to re-request the CSS resource (thus updating the style sheet). Budo does this by checking the --dir folders to determine a URL that is relative to the server. So, for example, if --dir=public/ then the URL will be /css/app.css, if --dir=. (default) then the URL will be /public/css/app.css.

Multiple static directories (the ability to do multiple -d) is a handy feature, but also a bit of a bag of worms. When you have multiple directories, you have multiple places the CSS could be. Budo has no way of knowing whether it should re-request /css/app.css or /public/css/app.css, since it doesn't know what you've defined in your HTML paths.

Maybe one option would be to, in the case of multiple --dir options, send a flag to reload-css so that the URL matching is fuzzy instead of strict. This will probably create other issues, though, as suddenly some applications will be re-requesting more CSS files than expected.

I'll have to brew on this a bit more... any suggestions are welcome, though.

dbrgn commented 6 years ago

Ah, that makes sense! Thanks a lot for taking a look :slightly_smiling_face:

The suggested workaround seems to do the trick! :+1: