-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
docs: clarify multiple entry point examples #7739
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
Conversation
Simplified multiple entry point examples to avoid confusion around entry keys and file paths. Follow-up to webpack#7328 with updated examples based on @evenstensberg feedback. url: webpack#7328
|
@cengizilhan is attempting to deploy a commit to the OpenJS Foundation Team on Vercel. A member of the Team first needs to authorize it. |
Adds a clarifying comment to explain that entry keys represent logical output paths/names, while values point to source files on disk.
Updates the example to use simple, unique entry key names to better align with documentation expectations.
|
We need to fix linting issue and then we are good! |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
evenstensberg
left a comment
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.
lgtm, thanks Cengiz! ☀️
|
Thanks a lot Even! Appreciate the review and the guidance along the way 🙌 @evenstensberg |
Simplified multiple entry point examples to avoid confusion around entry keys and file paths.
Follow-up to #7328 and #7397, with updated examples based on @evenstensberg feedback.
This example is different from the original one. Folder paths in the key and value are used intentionally to demonstrate custom
fromandtopaths.Summary
Clarifies multiple entry point examples by simplifying entry keys and file paths to reduce potential confusion.
What kind of change does this PR introduce?
docs
Did you add tests for your changes?
Not applicable. This PR only updates documentation.
Does this PR introduce a breaking change?
No.
If relevant, what needs to be documented once your changes are merged or what have you already documented?
The documentation has already been updated in this PR.