architect/functions

`arc.static` invocations without using `options` won't work when deployed to AWS without a domain

filmaj opened this issue · 0 comments

Describe the issue
Based on the code in https://github.com/architect/functions/blob/master/src/static/index.js, I think that if you deploy to AWS and don't have a domain set up for your app (and thus will have /staging and /production URL path prefixes for all routes), any usage of arc.static without setting the second options argument to {stagePath: true} will yield an incorrect path (missing the first staging or production URL path segment). As far as I can tell, the only way to get arc.static to correctly prefix the stage name is by using this second options argument.

Steps to reproduce

Create a basic arc app with:

  1. a @static pragma
  • add a static asset under public/, e.g. public/foo.css
  1. a single @http route
  • have the route use @architect/functions and e.g. print out the path to the static asset via a call to arc.static('foo.css')
  1. make sure no domain is associated to the app

Run it in sandbox and load up the http function: displays the right path (/_static/foo.css).

Deploy it to AWS and load it up: womp womp. You'll get HTTP 403 responses from S3 because the stage URL prefix is missing: blahblahblah.amazonaws.com/_static/foo.css should be blahblahblah.amazonaws.com/staging/_static/foo.css.

Expected behavior
Works in both sandbox and deployed to AWS.

Additional context
The workaround is to call arc.static with an options argument that looks like {stagePath: true}. In sandbox, stagePath will be ignored (as there is logic in arc.static protecting against the local case). When deployed to AWS, it will get used in the path. Feels like this should be default behaviour? Though if I understand correctly, that will mess up apps that have and use a domain. Maybe it's simply a docs issue? Not sure.