Open jthegedus opened 2 years ago
I'd vote for exposing an firebaseSsrOutputFolder
in the adapter's config, and ignore the functions
property in firebase.json
.
// svelte.config.js
/** @type {import('@sveltejs/kit').Config} */
const config = {
kit: {
adapter: firebase({
firebaseSsrOutputFolder: 'functions-ssr'
}),
}
};
If the option is passed, the adapter would overwrite (in this case) functions-ssr/lib
safely, including the index.js
that currently has to be modified by hand.
If the option is missing, then the adapter would output the code to the console, as it does now.
I think this would be the least confusing way to do it, at least for my simpler use case/firebase config. (Alternatives would be to specify the codebase name in the adapter config, or say that everyone has to use the same hardcoded codebase name.)
BTW, my current workaround is to copy firebase.json
(which has the codebase
array config) to firebase-ssr.json
, removing the array and pointing source
directly to the ssr folder. This works and deploys fine, but is obviously not ideal.
//firebase.json
"functions": [
{
"source": "functions",
"codebase": "functions"
},
{
"source": "functions-ssr",
"codebase": "ssr"
}
],
// firebase-ssr.json
"functions": {
"source": "functions-ssr"
},
// svelte.config.js
/** @type {import('@sveltejs/kit').Config} */
const config = {
kit: {
adapter: firebase({
firebaseJsonPath: 'firebase-ssr.json'
}),
}
};
While I intend to explore the above options for this adapter, I am also looking at contributing a solution to the actual firebase-frameworks lib. Depending on the difficulty, it could be a better option. Time and focus on a single project is my biggest restriction to bandwidth on these things. Thanks for your patience.
If you don't mind, I have some bandwidth and could work on the codebases feature.
If you don't mind, I have some bandwidth and could work on the codebases feature.
Awesome, please submit a PR and we can discuss the specifics there :100: :smile:
I would love to see this!
Potential first-party Firebase support for SvelteKit:
@ideodora looks good! I am just wondering how to use it 😅
@simpros me too 😢
@ideodora with today it is published in firebase-tools (v11.26.0). I have tried to follow the tutorial but no success with the @sveltejs/adapter-node build... Have to work more on it
Ok, I just spent a couple of hours trying different ways to do this and I think I figured it out. The way to go is with the new frameworks tools.
Update to the latest firebase-tools: v11.28
On firebase.json:
"hosting": {
"source": ".",
}
On svelte.config.js
set it to use the auto adapter.
import autoadapter from '@sveltejs/adapter-auto';
/** @type {import('@sveltejs/kit').Config} */
const config = {
kit:{
adapter: autoadapter(),
...
Run firebase deploy
.
This will build the static site and push it to firebase hosting and also build a node version, firebase will create a new container and create a new cloud run function.
Go to your domain and any regular routes will be served statically. Any ones that fail, like 404s will go to the cloudfunction, i can see the 404 requests going there.
Now I need to figure out if with some rewrite rules I can make just some specific routes go to the ssr function.
Describe the problem
Firebase have recently added features which will impact the development of this Adapter.
1: codebases - allow the configuration of multiple folders of functions. This would be useful to separate out the Cloud Function used for SSR from the rest of your codebases functions.
2: firebase deploy - is using some other mechanism referred to as "Firebase Frameworks" to allow the deploy command to know how to build and deploy SSR applications from meta-frameworks like Next.js etc. Next.js & Angular are currently supported.
Describe the proposed solution
I need to experiment with how these features work and might impact this adapter.
Given there was no closed-alpha or beta of these features (that I am aware of, I am part of the alpha and active in this space but never heard anything), I wouldn't be surprised if the Firebase team implemented their own SvelteKit integration with the new
firebase deploy
feature.Depending on the boundaries of the
firebase deploy
feature, the adapter may still be required.If this adapter is still required, I am thinking that Codebases gives a nice boundary for us to separate out the Cloud Function for SSR from the rest of peoples apps, which means pre-deployment compilation is easier, as is support for TypeScript.
With Codebases being a user-land feature I propose we implement that now, regardless of the
firebase deploy
status, and we can at least simplify the usage of the current adapter.Alternatives considered
NA
Importance
would make my life easier
EDIT: