Fix relative imports when using propshaft without a bundler

[Caleb-T-Owens]

• Related Download all the files associated with a package from a CDN importmap-rails#235

What is the problem that this solves?

Traditionally, when using propshaft with a JS build tool, your build tool will resolve all of your relative imports and bundles them into one JS file that propshaft can then serve.

With the move towards no-build JS however, when we take out the bundler, we start to run into an issue with how propshaft digests files.

For example, if I have:

// File a.js
import { foobar } from "./b.js"

foobar()

// File b.js
export function foobar() {
  console.log("Foo!")
}

Propshaft would serve railsyapp.test/assets/a-a2f3g5c5.js and railsyapp.test/assets/b-d4g6s2f4.js

HOWEVER because the JS imports are not updated to the served asset names, the import in a.js will fail, because b.js is really b-d4g6s2f4.js

Ok, so why can't people just use importmap-rails' pin_all_from function to pin all of their JS and use those named imports?

While this works for JS that has been newly written for the propshaft/importmap-rails environment, it falls short on two fronts.

1. Firstly and most importantly, when it comes to importing a library with multiple files (Related Import Map doesn't support CDN based directories importmap-rails#91) all of the imports in that library will need updating.
2. Secondly, if we support relative imports, this will make the transition from other bundlers much tidier as we won't have to get rid of all relative imports

[dhh]

I appreciate what this is trying to do, but I think it's veering too far into an understanding of JS path resolution that's not appropriate for Propshaft. The #nobuild path does indeed rely on having JavaScript that's written to be served directly to the browser. Relative paths are not valid within the context of a browser's JS.

I think you're going to want to use a JS preprocessor when dealing with legacy/third party JS that isn't fit for direct serving in the browser.