publicPath should not include RAILS_RELATIVE_URL_ROOT

[sspread]

It's my understanding that all paths defined in rails server are relative to the RAILS_RELATIVE_URL_ROOT, and webpack publicPath should behave the same way. For example:

RAILS_RELATIVE_URL_ROOT = /app
public_output_path = packs (webpacker.yml)

Working result would be
javascript_pack_tag -> <script src= '/app/packs/...'>
manifest.json -> /packs/...
publicPath -> /packs

However, under the current implementation,
javascript_pack_tag -> <script src= '/app/packs/...'>
manifest.json -> /packs/...
publicPath -> /app/packs
which will not be found because rails assumes routes relative to RAILS_RELATIVE_URL_ROOT.

See: #1357 and comments. Essentially I'm proposing that the merged code that addresses that issue should be reverted. Maybe something changed since then or maybe I'm missing something.

[jakeNiemiec]

What is the difference between public_output_path and RAILS_RELATIVE_URL_ROOT? Do we need both?

[sspread]

I believe public_output_path is supposed to be synonymous with webpack's publicPath. Under the current Webpacker config, publicPath now becomes RAILS_RELATIVE_URL_ROOT + public_output_path.

RAILS_RELATIVE_URL_ROOT is used to configure rails to mount on a sub-directory. If configured, rails already assumes the relative url root as the base, and it need not be a concern for webpack/webpacker.

[rdavid369]

If configured, rails already assumes the relative url root as the base, and it need not be a concern for webpack/webpacker.

Not in all cases. If I require a css file inside my module and said css file includes an image from it's package, that image doesn't properly load. It doesn't know anything about the relative url root. It becomes a broken asset. It works fine if the app isn't deployed in a sub directory. But for apps in sub directories, which is what we use relative url root for in the first place, it breaks.

How is everyone else telling webpack that the app is deployed in a sub directory, so assets properly load?

[GUI]

@rdavid369: I'm facing similar issues with image URLs inside CSS files being broken, since they don't have knowledge of RAILS_RELATIVE_URL_ROOT, so they try to load absolute paths like /packs/media/images/example.png instead of /my-relative-url-root/packs/media/images/example.png.

I've been able to workaround this issue by essentially bringing back the changes in #1428, although I'm not totally certain if this is the correct solution. But it at least seems to be working for me so far. I've patched things by prepending this to the very beginning of config/webpack/environment.js (before the initial require('@rails/webpacker')):

const config = require('@rails/webpacker/package/config');
if (process.env.RAILS_RELATIVE_URL_ROOT) {
  const path = require('path');
  config.publicPath = path.join(process.env.WEBPACKER_ASSET_HOST || '/', process.env.RAILS_RELATIVE_URL_ROOT, `${config.public_output_path}/`);
  config.publicPathWithoutCDN = path.join(process.env.RAILS_RELATIVE_URL_ROOT, `${config.public_output_path}/`);
}

[rdavid369]

@GUI I will give this a try! Much appreciated!

[LiiKaz]

@GUI you saved my day !

Is there still no other way to make this working ?

[johrstrom]

@GUI's solution worked for me as well. It seems like resolve-url-loader as described in the 4.x css docs https://github.com/rails/webpacker/blob/4e5ba661031d8481761662c4a845f16caad6a41a/docs/css.md should work, but did not prefix with a default configuration. I'm trying to migrate font-awesome from the ruby gem into webpack in rails 6.0 for reference, and new to the webpack stack so admittedly - I could be missing something fundamental here. But it seems like resolve-url-loader should prefix it.