0

Trying to create a simpler dev-test-prod workflow for my client-side dev where I don't have a developer site option.

I have a live site where I only have access to add scripts to the HEAD via a browser-based interface (think Wordpress/Shopify/etc). Using this option, I've been able to deploy working client-side apps by adding references to JavaScript bundles (created with webpack4) that I host in a a CDN I manage (that has CORS enabled). There is no development site. When I want to make changes to the app, I've been deploying those changes as testing in production. To avoid breaking changes for my users, I iteratively do very minor changes so I can quickly rollback.

What I'd like to do is find a way to change just MY experience so that for just my experience I hijack requests to specific JS files when using the live site.

I've tried using Chrome's local workspace & offline file feature, but I'm running into issues where the webpack generated JS files are failing to load from my local environment with CORS errors. However other scripts are loading just fine.

Specifically: I have three files, alpha.js, beta.bundle.js & charlie.bundle.js... the latter two are webpack bundles, the "alpha" file is a plain JS file that runs code in the global scope (it's similar to what the Google Analytics script does). All three are hosted and loaded from the same CDN. I can use Chrome's offline files and hijack alpha.js without a problem, but the beta & charlie bundles report CORS issues.

Two questions: (1) why would the webpack bundles cause CORS issues while the alpha.js file doesn't & (2) is there a better option for what I'm trying to achieve (without creating a dev site which is not an option)?

Andrew Connell
  • 4,939
  • 5
  • 30
  • 42

1 Answers1

0

Local Overrides should do the trick.

Check out this other Stack Overflow answer where I explain how to set up Overrides and how they work.

Once you've got Overrides enabled, you'll want to drop your alpha.js, beta.bundle.js and charlie.bundle.js into your Overrides folder. I think the path to the files needs to be the same as the paths specified in production.

Kayce Basques
  • 23,849
  • 11
  • 86
  • 120
  • That's what I thought, in fact, I followed your instructions from the docs... but just duplicated it again. You can try for yourself... the site is https://www.voitanos.io. Set it up and edit the file https://vtnscdn.azureedge.net/assets/drip2.js... I added the obnoxious `alert('hi from drip2.js');`, saved and reloaded the page. Worked as expected showing the alert. Then did the same with the file "voitanos-core.bundle-#####.min.js" (same path)... didn't work this time & I see classic CORS error in the console & Network... can't figure out why this triggers a CORS error though... ideas? – Andrew Connell Jan 11 '19 at 23:23
  • Sorry, I'm not following your comment. Are you saying that Local Overrides isn't working for your use case? – Kayce Basques Jan 11 '19 at 23:24
  • Yeah... sorry... hit enter too fast and was editting the comment... see updated comment above. – Andrew Connell Jan 11 '19 at 23:25
  • I understand that the "drip2.js" script reference doesn't have **crossorigin** attrbute while the others do, but my understanding is the default value is used when the attribute is omitted so having it present or not is the same as setting `crossorigin="anonymous"`. – Andrew Connell Jan 11 '19 at 23:31
  • 1
    Ah, looks like a bug. That CORS stuff is probably just some weird byproduct of the Local Overrides bug. Filed an issue here: https://crbug.com/921233 – Kayce Basques Jan 11 '19 at 23:54
  • Thanks for the followup! I'll keep an eye on the bug. – Andrew Connell Jan 12 '19 at 10:29