-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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 @auth/astro framework library #9856
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
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.
Thanks! Added some comments!
Besides those, have a look at https://github.com/nextauthjs/next-auth/blob/main/packages/utils/scripts/providers.js
Used eg. here:
next-auth/packages/next-auth/package.json
Lines 61 to 65 in f33a0ac
"build": "pnpm clean && pnpm providers && tsc", | |
"clean": "rm -rf *.js *.d.ts* lib providers", | |
"dev": "pnpm providers && tsc -w", | |
"test": "vitest -c ../utils/vitest.config.ts", | |
"providers": "node ../utils/scripts/providers" |
This way, users can import providers from @auth/astro/providers/*
instead of having to install @auth/core
!
Further, for other integrations support automatic environment variable inference by using the setEnvDefaults
method like so
setEnvDefaults(process.env, config) |
there is also createActionURL
, a method from core that helps you create the url for the Request
of Auth
in a much less hacky way!
And lastly, the default basePath
value is expected to be /auth
, not /api/auth
. (NextAuth.js is the only exception, since historically that was the default basePath there and we did not want to make this a breaking change in v5)
Could you incorporate these changes, and then make sure that the dev app and example app is also correctly updated? 🙏 Thanks!
".": "./src/index.ts", | ||
"./config": "./src/config.ts", | ||
"./client": "./src/client.ts", | ||
"./server": "./src/server.ts", | ||
"./middleware": "./middleware.ts" |
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.
".": "./src/index.ts", | |
"./config": "./src/config.ts", | |
"./client": "./src/client.ts", | |
"./server": "./src/server.ts", | |
"./middleware": "./middleware.ts" | |
".": { | |
"types": "./index.d.ts", | |
"import": "./index.js" | |
}, | |
"./config": { | |
"types": "./config.d.ts", | |
"import": "./config.js" | |
}, | |
"./client": { | |
"types": "./client.d.ts", | |
"import": "./client.js" | |
}, | |
"./server": { | |
"types": "./server.d.ts", | |
"import": "./server.js" | |
}, | |
"./middleware": { | |
"types": "./middleware.d.ts", | |
"import": "./middleware.js" | |
}, | |
"./adapters": { | |
"types": "./adapters.d.ts" | |
}, | |
"./providers/*": { | |
"types": "./providers/*.d.ts", | |
"import": "./providers/*.js" | |
} |
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.
The Astro package doesn't require bundling, as all Astro projects (regardless of config) support TypeScript files. Is there still a reason to specify both types
and import
if they both lead to the same file?
Co-authored-by: Balázs Orbán <[email protected]>
Co-authored-by: Balázs Orbán <[email protected]>
…, clean up file structure
Is there any further things blocking this from getting merged? I'd love to start using it |
There seem to be some merge conflicts. Otherwise it should be close. Needs another last going over, testing, etc. |
@ndom91 happy to resolve the conflict, seems to just be the pnpm-lock, so I'll try to do this tonight. Also, I have some notes from the last review in Discord that might be relevant when going over for another round of reviewing. I also know there's been work on the framework guidelines? I've not been able to keep up as much as I wanted, so let me know if I'm missing anything important from those! |
Awesome, thanks! Yeah no I don't think there were any changes there. There's just this creating a framework pkg guidelines 👍 |
@TheOtterlord is attempting to deploy a commit to the authjs Team on Vercel. A member of the Team first needs to authorize it. |
Probably better that you don't do that. |
I would prefer to use Auth.js since I am familar with it but since this PR is clearly not going to get merged, at least any time soon, I've switched to |
I also hope this does get merged! |
Has anyone been able to run the fork with the installed PR? I'm stuck because the middleware isn't attaching due to an error in vite-plugin-astro-server/request.js: 'Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. Received protocol 'auth:'.' |
I have not, but seems that there is still some work being done by @TheOtterlord & @ndom91 |
I just finished converting my Astro starter kit to Lucia v4 (the latest version), and although it took some time, I would say it's a pretty good alternative. There are some examples that you can follow for guidance: https://github.com/orgs/lucia-auth/repositories?q=astro |
☕️ Reasoning
Introduces an Astro framework package. The package exposes an integration, along with helper methods for both server & client uses.
🧢 Checklist
🎫 Affected issues
📌 Resources