-
Notifications
You must be signed in to change notification settings - Fork 513
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
feat: add entry to build info #1649
Conversation
@@ -405,6 +405,7 @@ async function _build(nitro: Nitro, rollupConfig: RollupConfig) { | |||
const buildInfo = { | |||
date: new Date(), | |||
preset: nitro.options.preset, | |||
entry: nitro.options.entry.split("/").pop(), |
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.
This is the source entry name not a build output information...
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.
Yes, this is useful for presets like firebase, where one preset can have multiple entries :
ie looking at the build output of a firebase preset build, we can't know if firebase-gen-1
or firebase-gen-2
is being used.
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.
I know that's a valid case but generally it doesn't seems to be best idea to add source entry to production info. It can be implemented per preset imo.
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.
That's a good point, what about renaming the preset if it's firebase with a hook? Something like firebase_${variant}
?
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.
Renaming the user-input preset can also lead to more confusing behavior.
Thanks for the PR @Hebilicious. I guess i would prefer to use current method for firebase preset at least to keep the preset implementations simplicity and decoupled as much as possible. While current approach for firebase gen handling is not perfect, i am happy to discuss about some other alternative ideas once we migrated repo to a monorepo. Also we can use virtual chunks for entry or simply support dynamic entry based on user input config (it was absence by the time of implementing that PR...) |
π Linked issue
resolves #1650
β Type of change
π Description
While working on #1557, I noticed that for presets that can have multiple entries, like firebase, there's no straightforward way to identify which one has been used. This adds a reference to the preset used in the build info.
π Checklist