Bundle JS breaks existing deploys

Site: http://emailable.netlify.app
Domain: https://emailable.com

  1. Enabling Bundle JS impacts all previous and current deploys. This in itself makes it impossible to test without breaking the current deploy which is less than ideal at best.

  2. Without Bundle JS it appears the JS files aren’t asset hashed and loaded from Cloudfront.

  3. When Bundle JS is enabled it breaks the site. For example the all.js file (https://d33wubrfki0l68.cloudfront.net/js/531a7ec7396faccfcbe697596ad7f68d01abcad4/javascripts/all.js) loads perfectly fine. The browser then tries to load various imports like https://d33wubrfki0l68.cloudfront.net/js/531a7ec7396faccfcbe697596ad7f68d01abcad4/javascripts/206.js which 404s even though the file is available at https://emailable.com/javascripts/206.js. How is this possible?

Hiya @jclusso and sorry to hear about the trouble!

That’s how the feature works. unfortunately - if a file isn’t modified, it is not hosted on the cloudfront bucket and so “relative” references to non-modified files will potentially break. You could probably update all your references to be full (https://site.com/asset rather than /asset) to work around it.

However, I’d suggest disabling our asset optimization and using something you bring into your project yourself - there are dozens of node modules to optimize assets that will likely work better than ours, and will allow you to control them, and won’t monkey around with asset paths in ways that could break your site.

We’re also happy to file a bug report, but based on past similar reports, it’s unlikely we’ll be able to fix it and it should be possible to work around by not using our feature (since there are many equivalent-behaving packages available for you to use directly during build). So, if you want to gather up files to help us file a report (essentially, we’ll need a copy of your site’s source code, that we can snapshot and keep a copy of.), we’ll be happy to file it - but I’d expect that the way you can get your site working quickly will be to not use that feature, so I wanted to say that before you spent time gathering more details for us.

Hi @fool,

I’m confused by your response. I have 3 problems here, and I only believe you addressed the last one. I sort of understand what you are saying. The problem with your solution is that #2 still exists. #1 also vioates the concept of deploys being atomic.

Hi @jclusso,

I believe we’re discussing this in the helpdesk. I can see you’ve some additional questions, which I’ll revert to after spending some time on the forums. :slight_smile: