0
votes

I'm building my first tiny Phoenix app and ran into a super annoying issue:

Every time I make a change to a JS file e.g. web/static/js/socket.js Brunch is picking up the change and recompiling priv/static/js/app.js. I have verified that the changes are actually compiled into app.js correctly.

However, I cannot make the server serve the updated files to the clients. Any ideas how I can make cache invalidation work correctly? Could it be a configuration issue with Cowboy?

Notice: I'm running the server inside a Vagrant box (Ubuntu) and the browser on the host machine (OSX).

Update: This is turning into a mystery! Apparently the content of the response comes from the cached file but the length is determined by the length of the file on disk.

Examples:
echo "hey" > foo.js
(Filesize 4)
Response for curl http://localhost:4000/js/foo.js is hey\n

printf "." > foo.js
(Filesize 1)
Response: h

printf "1234567890" > foo.js
(Filesize 10)
Response (in hex): 6865 790a 0000 0000 0000 (Response is hey\n followed by blank padding)

1
This is on a full page refresh? You get the old app.js served when you reload the page in the browser? Is this in dev or prod?Dogbert
Yes, on a full page reload. I'm using cURL to make sure it has nothing to do with browser caching. It is in dev. I tried dropping a new file (foo.js) into priv/static/js and that has the same problem. Server will pick up the new file but and keep serving the original content even after changes in the file.jonasmaturana

1 Answers

1
votes

Turns out to be a known issue with Virtual Box' Shared file system.
Switching to NFS solved the problem.

A comment on issue 812 in the Cowboy project describes my exact problem: https://github.com/ninenines/cowboy/issues/812

In addition to that it might be useful to configure Brunch to use polling if changes to your JS files are not picket up. You can do that by adding the following snippet to brunch-config.js.

watcher: {
  usePolling: true
},