Using public URL for dynamic imports

[PurpleHexagon]

💬 RFC

When using code splitting and thus dynamic imports allow for public URL to be specified rather than trying to determine base URL based on stacktrace

🔦 Context

I am currently trying to get a React application working on some complex infrastructure which is out of my control. Due to the way this works the URL matched it the Error.stack is not correct ... referenced here #2434 which is basically this code https://github.com/parcel-bundler/parcel/blob/v2/packages/runtimes/js/src/bundle-url.js#L23 (Not sure if that is the right file as function is defined multiple places)

I would like to be able to use the public url which is already being passed into the parcel command in our case.

💻 Examples

Possible solution

parcel src/app.html -d dist/output/ --cache-dir .cache/output/ --public-url https://example.com/dist_alias --use-public-url-for-import true

And then check for this flag before trying to match the base url from error trace.

But am really open to anything that will allow for us to get the application working on this infrastructure.

[mischnic]

I think you are using Parcel 1 but referring to the sources for Parcel 2.

Could you share more details about your environment?

[PurpleHexagon]

You are correct I am using Parcel 1 ... the correct file should have been https://github.com/parcel-bundler/parcel/blob/1.x/src/builtins/bundle-url.js ... I just did a search on Github for the code and didn't see the version number.

I don't know too much about the environment but basically the React application that parcel is bundling up is hosted within AWS and is then embedded into Abobe Experience Manager.

Everything works fine until the application is embedded in the CMS where the include of the first lazy loaded js file will break as the base url is incorrect.

The include is basically picking up the base url of the CMS as the React app is included via JavaScript.

So the error thrown in getBundleUrl when using debugger is:

Catch

err: Error at getBundleURL (eval at globalEval (https://example.com/etc/cms/assets.js:1:534543), :30447:11) at getBundleURLCached (eval at globalEval (https://example.com/etc/cms/assets.js:1:534543), :30438:17) at loadBundle (eval at globalEval (https://example.com/etc/cms/assets.js:1:534543), :30521:43) at Array.map () at loadBundles (eval at globalEval (https://example.com/etc/cms/assets.js:1:534543), :30491:30) at eval (eval at globalEval (https://example.com/etc/cms/assets.js:1:534543), :30480:9) at new Promise () at LazyPromise.then (eval at globalEval (https://example.com/etc/cms/assets.js:1:534543), :30540:45)

Local

matches: Array(6)
0: "https://example.com/etc/cms/assets.js:1:534543"
1: "https://example.com/etc/cms/assets.js:1:534543"
2: "https://example.com/etc/cms/assets.js:1:534543"
3: "https://example.com/etc/cms/assets.js:1:534543"
4: "https://example.com/etc/cms/assets.js:1:534543"
5: "https://example.com/etc/cms/assets.js:1:534543"
length: 6
proto: Array(0)

So base url ends up being https://example.com/etc/cms/ rather than https://example.com/parcel-dist

[PurpleHexagon]

@mischnic Did you have any thoughts on how we might resolve this issue? I'm happy to do some development work. Looks like this issue will also be present in Parcel 2. Would be great if there was a way to not have to fork the repo. Also having trouble working out best way to get the public url into each generated file at time bundle is created.

[mischnic]

So the main bundle is loaded as example.com/etc/cms/assets.js and all of the other assets/JS bundles are in example.com/parcel-dist? (Did this happen because the entry bundle was somehow bundled again?)

For Parcel 2, all of this bundle loading is implemented in the js runtime plugin:

parcel/packages/runtimes/js/src/JSRuntime.js

Line 340 in d19bee1

function getRelativePathExpr(from: NamedBundle, to: NamedBundle): string {

So in the worst case, you could use your own runtime plugin instead of the default one (without "forking" Parcel itself)

[PurpleHexagon]

example.com/etc/cms/assets.js is a script that is tasked with embedding the html output from Parcel which then loads the bundled js etc but with the wrong path. Its part of how SPAs are embedded into this particular CMS I believe.

Thank you for the information regarding Parcel 2 that looks like it could make things much easier, as you say without forking.

Is there any rough schedule of how long V2 will be in beta?

Thanks again for your help and for the information regarding Parcel 2 runtime plugins.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.