-
-
Notifications
You must be signed in to change notification settings - Fork 9.1k
resolving issue #19057 #19061
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
resolving issue #19057 #19061
Conversation
|
For maintainers only:
|
@jalajk3004 Please accept CLA |
@alexander-akait i have accepted the CLA |
Check your git email |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexander-akait i have created the cla.yml file, and also signed the CLA
074dc7c1-4bee-4662-aa6f-c962f7834bc5.pdf
.github/workflows/cla.yml
Outdated
#custom-pr-sign-comment: 'The signature to be committed in order to sign the CLA' | ||
#custom-allsigned-prcomment: 'pull request comment when all contributors has signed, defaults to **CLA Assistant Lite bot** All Contributors have signed the CLA.' | ||
#lock-pullrequest-aftermerge: false - if you don't want this bot to automatically lock the pull request after merging (default - true) | ||
#use-dco-flag: true - If you are using DCO instead of CLA |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed
@alexander-akait it would be great if you guide me like what's wrong in the PR or has not the CLA signed yet? |
@jalajk3004 Can you provide code where you faced with such problem? We need to add a test case, thank you |
What kind of change does this PR introduce?
Does this PR introduce a breaking change?
The fix is backward-compatible and enhances Webpack's ability to handle dynamic paths without impacting existing configurations or workflows.
What needs to be documented once your changes are merged?
Update documentation to explain the fallback mechanisms for determining the script URL, including:
Include examples for explicitly setting output.publicPath when needed.
I made the changes in the AutoPublicPathRuntimeModule.js
hope this resolves the bug