Manifest includes assets_url in v4.0.0.rc.2

[JanStevens]

Hello

In version v4.0.0.rc.2 now generates a manifest.json file that includes the configured asset host

{
  "admin.css": "https://xxxxx.cloudfront.net/packs/admin-e902804e.css",
}

In my production.rb I got

config.action_controller.asset_host = "https://xxxxx.cloudfront.net"

And my environment.js has

const splitChunks = {
  optimization: {
    runtimeChunk: false,
    splitChunks: {
      chunks: 'all'
    }
  }
}

environment.config.merge(splitChunks)

environment.plugins.insert(
  'Manifest',
  new WebpackAssetsManifest({
    integrity: false,
    entrypoints: true,
    writeToDisk: true,
    publicPath: true
  })
)

In version v4.0.0.pre.3 the same settings would generate the manifest as followed:

{
  "admin.css": "/packs/admin-e902804e.css",
}

I do want to turn this off, since I do not know during compilation of my assets the cloudfront url and my devops team might want to change the cloudfront url. This would now mean we have to recompile assets again.

We compile assets and upload them to S3 using

 env RAILS_ENV=production env NODE_ENV=production bundle exec rake webpacker:compile   

Regards

[gauravtiwari]

Thanks for reporting, let me take a look 👍

[iggant]

@gauravtiwari If this is not a bug, can you please explain why this happens, and can this will be fixed by any config parameter?

[marcohamersma]

@gauravtiwari I think this is breaking stuff for our users. Just adding wontfix without any explanation is not very communicative.

update:
To elaborate a bit on how it breaks; we use Heroku's pipeline feature for our deployment. Which for us means that assets will get built for the staging environment, and then the app gets "promoted" to production, and assets will not change anymore.

From the Heroku docs:

When a slug is promoted, Heroku copies it without making any changes. It is not rebuilt for the environment of the target app. If your builds bake in environment from the build-app context, then your slugs are not portable between pipeline stages.

Considering that our staging setup has a separate CDN url, this means that staging's CDN url is now baked in to the asset manifest file. I noticed there might ways of dealing with this by adding extra steps to the Procfile, but this is a bit of a hassle and I'd rather have that this type of default workflow would just work out of the box like the 3.x version of Webpacker.

[joelmoss]

Just adding wontfix without any explanation is not very communicative.

Extremely unhelpful, and not in the spirit of open source at all :(

[guilleiguaran]

Please take a look to #1973