You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
🐛 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 thechrome-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
The text was updated successfully, but these errors were encountered: