-
Notifications
You must be signed in to change notification settings - Fork 10
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
single file bundles (SFBs) for SSR page and API routes #1118
Labels
Adapter
alpha.0
CLI
enhancement
Improve something existing (e.g. no docs, new APIs, etc)
sponsorship:claimed
sponsorship:eligible
SSR
v0.30.0
Milestone
Comments
thescientist13
added
enhancement
Improve something existing (e.g. no docs, new APIs, etc)
CLI
SSR
labels
Jun 25, 2023
This was referenced Jun 25, 2023
thescientist13
changed the title
single file SSR page and API route production bundles
single file executables for SSR page and API route production bundles
Jul 8, 2023
So it seems like Rollup doesn't support this and seems like it's not a particularly easy thing to do. However an interim solution seems to be something like this where we have to manually "squash" down into single file entry points by individually running each entry point through it's own Rollup config, instead of passing all entry points to Rollup into a single config, like we do now. |
thescientist13
changed the title
single file executables for SSR page and API route production bundles
single file executables (SFEs) for SSR page and API route production bundles
Jul 23, 2023
2 tasks
12 tasks
thescientist13
moved this to 🔖 Ready
in [Greenwood] Phase 9 - Standards and Conventions
Oct 17, 2023
5 tasks
thescientist13
moved this from 🔖 Ready
to 🏗 In progress
in [Greenwood] Phase 9 - Standards and Conventions
Dec 7, 2023
thescientist13
moved this from 🏗 In progress
to 👀 In review
in [Greenwood] Phase 9 - Standards and Conventions
Dec 14, 2023
thescientist13
moved this from 👀 In review
to 🏗 In progress
in [Greenwood] Phase 9 - Standards and Conventions
Feb 19, 2024
thescientist13
moved this from 🏗 In progress
to 👀 In review
in [Greenwood] Phase 9 - Standards and Conventions
Feb 20, 2024
thescientist13
changed the title
single file executables (SFEs) for SSR page and API route production bundles
single file bundles (SFBs) for SSR page and API routes
Mar 9, 2024
github-project-automation
bot
moved this from 👀 In review
to ✅ Done
in [Greenwood] Phase 9 - Standards and Conventions
Mar 10, 2024
Merged
39 tasks
This was referenced Mar 10, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Adapter
alpha.0
CLI
enhancement
Improve something existing (e.g. no docs, new APIs, etc)
sponsorship:claimed
sponsorship:eligible
SSR
v0.30.0
Summary
Coming out of the PR for #1088 wanted to track an issue around the output of the bundle files created for SSR page and API route bundles. It would be nice to make sure all these files are as self contained as possible to not have to rely on any particular bundling setups for different hosting providers.
In particular this applies to SSR pages, as currently two output files are generated
__<page>.js
- the entry point file used to invoke a_<page>.js
file that exports itself as ahandler
function (like in theserver
command)_<page>.js
- the bundled output ofexecuteModuleUrl
Another (potential) complication / urgency for this has been observed in thescientist13/greenwood-lit-ssr#3 where in now our page output bundling is not consistent, because we have to do hacky things like this. 😬
In general there should be a way to collapse down a lot of these files into one. 🙏
Details
One particular callout on this is that WCC take a
URL
forrenderToString
as the entry point, which means at least one file has to exist on disk I guess, meaning there will always be an entry point and then the actual userland code?In addition this would also mean making sure Rollup doesn't create chunks.
edit: also, coming out #1122 and the actual prototypes for the Vercel and Netlify adapters, the current implementation of adapter plugins by their current design also introduce an entry point, which also seems by nature of the design, e.g.
Also see examples of this in the adapter plugins that have to copy a bunch of files around when preparing for uploading to the respective hosting platform
The text was updated successfully, but these errors were encountered: