Would there be any advantages to using webpack-dev-server?
I find BrowserSync works well, has a nice interface and is easy to access from other devices. And, from memory when I worked on the Sage/webpack config, I found webpack-dev-server to be too much oriented toward js app and Sage is not that.
BrowserSync has better features, allows for multiple device testing out of the box, includes a great admin panel for more control and bandwidth throttling which is helpful to test for speed and loading. I see no reason to switch.
Despite the affiliation to Trellis, thanks to Docker for Mac/Windows Beta, a vanilla wordrpess site or even a bedrock config is one command away docker-compose up -d. However, Browsersync is pretty weird to configure inside of docker, webpack is much less so.
@jaredpalmer i haven't yet dug into docker (finally bout to) so i'm not sure what steps are needed in order to get browsersync working with it. can you provide more details?
normally it's recommended to run node on the host machine and not on your vm/dev box. is that not the case with docker?
@jaredpalmer @retlehs I run wordpress in docker, and i just run webpack on the outside. No problem.
@jeger Do you mind sharing your docker-compose.yml file?
If I recall, I was using a very very early version Docker for Mac Beta when I filed this issue when there was a bug in the native file watcher. Regardless, I still think browser-sync is kinda overkill.
If I recall, mine looked like this:
version: '2'
services:
db:
image: mysql:5.7
volumes:
- "./.data/db:/var/lib/mysql"
restart: always
environment:
MYSQL_ROOT_PASSWORD: wordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress:4.5.2-apache
volumes:
- ".:/var/www/html/wp-content/themes/sage"
links:
- db
ports:
- "8080:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_PASSWORD: wordpress
@jaredpalmer That would probably explain it, docker now runs much better on MacOS. My Docker files are kinda extensive and actually build from the (VVV)[https://github.com/Varying-Vagrant-Vagrants/VVV] project.
But there should be no problem with the file you pasted here. As far as i can see.
I didn't do anything special to get browsersync working.
Send me a message on twitter if you keep having problems with this tho :)
@Halvardos
@Jeger were you able to see live reload changes with browser-sync and docker? I wasn't able to. It served, but never updated. I also tried vanilla webpack-dev-server but was struggling to figure out the proxy config. I also found out that you have to use a wp filter to disable rel=canonical in order to prevent an auto redirect.
I know that sage is tied to trellis/roots/bedrock, but it's 2016 folks. People want immutable infra and twelve factor apps. IMHO this theme should work with docker-compose out of the box.
@jaredpalmer Did you run browsersync on the outside of the the container?
@jeger yup. Running it from my project root (and shared volume) locally outside any container. I was reading that there is a socket / port issue.
When I get to my office ~ 30min will post the link about the bSync ports. Can also publish a fork so we can talk apples to apples.
@jeger looks like I am also running an older version of sage 9. There has been some work done on the public path stuff recently. Will try again with a current fork. Stay tuned
Most helpful comment
Would there be any advantages to using webpack-dev-server?
I find BrowserSync works well, has a nice interface and is easy to access from other devices. And, from memory when I worked on the Sage/webpack config, I found webpack-dev-server to be too much oriented toward js app and Sage is not that.