App won't load in production: MIME type error on redirect to auth on Heroku Docker deployment

[siakaramalegos]

I'm getting a MIME type error on the auth HTML file only in production (deployed to Heroku using Docker):

Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec.

This is technically the index route that is getting redirected to auth. When holding down shift on the auth "script" file, we can see its initiator is a redirect from index.jsx:

Auth response preview:

It's definitely an HTML file:

Headers also indicate it's HTML:

But the app is expecting a JS module instead of an HTML file, and I'm not sure why - I guess because it's being redirected from index.jsx. This feels like an app config issue on auth redirects, but we didn't change any of the default configuration.

Note: app works fine in local development.

[siakaramalegos]

It seems like the app is trying to serve raw assets (index.jsx) rather than built ones (.html or .js)

This is related to #117 and #111.

Might be related to #108 and #109, but I'm still investigating.

[siakaramalegos]

We found the root cause of the issue - if you use Docker in Heroku, then the environment variables aren't available at build time: https://devcenter.heroku.com/articles/build-docker-images-heroku-yml#set-build-time-environment-variables

We're getting around it right now by hard-coding the values of SHOPIFY_API_KEY and RAILS_SERVE_STATIC_FILES directly in the Dockerfile, though it's not ideal. The deploy instructions should probably be updated to note something to this effect. Going to comment on the other issues in case people search for the same error.

[remy727]

We're getting around it right now by hard-coding the values of SHOPIFY_API_KEY and RAILS_SERVE_STATIC_FILES directly in the Dockerfile.

Shopify documentation already mentioned you can need to add SHOPIFY_API_KEY in heroku.yml

What does your Dockerfile look like?

# Dockerfile

FROM ruby:3.4.1-alpine

ARG SHOPIFY_API_KEY
ENV SHOPIFY_API_KEY=$SHOPIFY_API_KEY

# heroku.yml

build:
  docker:
    web: Dockerfile
  config:
    SHOPIFY_API_KEY: <YOUR_SHOPIFY_API_KEY>

[siakaramalegos]

I meant this literally:

We're getting around it right now by hard-coding the values of SHOPIFY_API_KEY and RAILS_SERVE_STATIC_FILES directly in the Dockerfile

ARG SHOPIFY_API_KEY
ENV SHOPIFY_API_KEY="abcde12345"

ARG RAILS_SERVE_STATIC_FILES
ENV RAILS_SERVE_STATIC_FILES=1

[remy727]

I'm sorry if misunderstood.
But we don't hard-code those ENVs in Dockerfile. We only hard-code them in heroku.yml

# Dockerfile

ARG SHOPIFY_API_KEY
ENV SHOPIFY_API_KEY=$SHOPIFY_API_KEY

[siakaramalegos]

Yes, I understood you the first time. I was just answering your question. It's still not ideal though - it's just saved in a different file that is still available in the repo.

[remy727]

Yes. You are right.
Heroku runtime config vars aren’t available at build time.
I have contacted the Heroku support team about this before but there was no solution. It is the limitation of this app template.