feat: adds session options #12450
feat: adds session options #12450
Conversation
|
github-actions
bot
added
pkg: astro
| * <a href="/checkout">🛒 {cart?.length ?? 0} items</a> | ||
| * | ||
| * ``` | ||
| * |
There was a problem hiding this comment.
Link to RFC to learn more, maybe?
There was a problem hiding this comment.
Yeah, I'll do that once I have the stage 3 PR up
Co-authored-by: Sarah Rainsberger <[email protected]>
Co-authored-by: Sarah Rainsberger <[email protected]>
| @@ -714,6 +733,13 @@ export function createRelativeSchema(cmd: string, fileProtocolRoot: string) { | |||
| }); | |||
| } | |||
| } | |||
| if (session && !experimental.sessions) { | |||
There was a problem hiding this comment.
I think it would be better to just have it under experimental, and move it to root once it becomes stable
There was a problem hiding this comment.
Still don't know what's the best thing there.
There was a problem hiding this comment.
Not that I get a say in the matter, but from a docs perspective, we prefer when everything related to an experimental feature is contained in its own experimental config. 😅
Especially going forward, each experimental feature will have its own page, separate from configuration reference. If everything is contained, it's nice to document all in one experimental feature flag, and we don't have to send people separately to configuration reference for configuring experimental things, and it's easier to know you've got the feature set up when it's all together.. (And, we get to keep experimental content separate from stable, which is more helpful for readers to keep things straight.)
And, separate page for experimental feature means you get to avoid JSDoc and just make normal docs PRs to update... so... does that tempt you??? 😄
On the other side, I think Ema said from a code maintenance or testing perspective, it's easier to work on the code separately from the flag. There's also the advantage of this showing up in the editor. (But then, it shows up for people who also don't have the flag enabled, too. Is that advertising or confusing?) So really, both sides have their benefits.
We can certainly handle documenting either way, and for sure don't want to suggest something difficult to work on or maintain. But if we got to choose, we'd keep the experimental configs within the experimental flag.
There was a problem hiding this comment.
You absolutely do get a say! I think I am swayed towards moving it all into experimental now, and replace the boolean with the object. The fact it's a new top-level option is the difference I think.
| */ export interface AstroUserConfig<TLocales extends Locales = never> { | ||
| */ export interface AstroUserConfig< | ||
| TLocales extends Locales = never, | ||
| TSession extends SessionDriverName = never, |
There was a problem hiding this comment.
I'm glad the generic defineConfig is used already :)
There was a problem hiding this comment.
Yeah, it works great!
Changes
Adds experimental flag for sessions, and top-level
sessionoptionsTesting
Docs