Parcel not using --public-url when resolving bundles via code-splitting

[rhurstdialpad]

🐛 bug report

When generating code with parcel that contains dynamic imports (code splitting) the expected path of secondary bundles is always expected to be at the root path and ignores the --public-url flag.

Update: It turns out that parcel uses a stack trace to resolve the path to the primary bundle, then uses this to determine the base path of secondary bundles. However this only works with files loaded from protocols http://, https://, 'ftp://', and 'file://'. I've created a pull request to support the chrome-extension:// protocol.

🤔 Expected Behavior

I expected parcel's module system to attempt to fetch the bundle with the value of --public-url as a prefix to the name of the bundle file.

😯 Current Behavior

Parcel's module system tries to fetch the bundle as if the secondary bundle is at the root path not taking --public-url into account.

💁 Possible Solution

Ideally Parcel's module system should fetch the bundle from the subpath of --public-url

🔦 Context

Bundling source in a chrome app where file paths are relative to the filesystem inside the chrome app.

🌍 Your Environment

Software	Version(s)
Parcel	1.11.0
Node	10.11.0
npm/Yarn	yarn 1.12.1
Operating System	macOS 10.14.1

[rhurstdialpad]

Figured it out. It's because chrome extensions and apps use a custom protocol chrome-extension which does not match the regex parcel uses to get the path of the current bundle.

See here => https://github.com/parcel-bundler/parcel/blob/master/packages/core/parcel-bundler/src/builtins/bundle-url.js#L15-L25

[rhurstdialpad]

I've created a pull request that adds the protocol here => #2434

[rhurstdialpad]

PR was merged, closing this as a result