Webpacker: 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 https://github.com/rails/webpacker/pull/1973

[gauravtiwari]

Sorry about not adding more info earlier. I was away :)

Basically, this is not a bug, in other words, it sort of like chicken-egg situation. Rails add CDN host through helper tags for all the assets included in the views, however, assets like images or font icons which are included inside JS code or CSS files don't have CDN if we don't supply full public path since it's processed by file loader, which uses webpack public path.

For example:

import Rails from 'rails'
import Rails2 from 'rails_assets'
import Google from 'some_namespace/google'

const Hello = props => (
  <div>Hello {props.name}!<img src={Google} /> <img src={Rails} /> <img src={Rails2} /></div>
)

Note: The images included above won't have CDN included since they are processed by webpack using file loader, unless we specify public path with CDN.

Now, current implementation works for both cases, since Rails is intelligent enough to figure out that a URI includes CDN host if we supply a CDN host to webpack and the generated URI includes CDN host, Rails doesn't add CDN host to it and the embedded assets also include CDN hosts.

I see, this might not be ideal for some cases like described above but this is the best we can get at the moment that's why I added won't fix label earlier.

If anyone has ideas, feel free to post.

[gauravtiwari]

Found a solution :)

[gauravtiwari]

Please see the PR

[marcohamersma]

Great! thanks for taking a look 🙂