-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Use the same option source for SSL (certs and keys) in Preview and Dev #1662
Conversation
We might want to add some documentation in the FAQ about this, instead of having to dig around in the Vite options to accommodate this. Please advise if you'd like me to add to the documentation. |
I'd also like to propose moving the cert and key options from Vite's config to Kit's config. Kit is responsible for setting up the server when in middlewares mode, so it's actually Kit that self-signs certificates and passes certificates to http(s).createServer. If this were to be implemented, I'd suggest the following changes:
Pros:
Cons:
I'm happy with any decision. I was hesitant on proposing this change, but I thought it might be worth a look. |
packages/kit/src/core/start/index.js
Outdated
@@ -48,7 +48,7 @@ export async function start({ port, host, config, https: use_https = false, cwd | |||
read: (file) => fs.readFileSync(join(config.kit.files.assets, file)) | |||
}); | |||
|
|||
const server = await get_server(use_https, config.kit, (req, res) => { | |||
const server = await get_server(use_https, config.kit.vite, (req, res) => { |
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 parameter name in get_server
and in dev
where it's being called (since #1517) is user_config
. It sounds like perhaps it should be renamed to vite_config
. also the type is any
which is allowing it to be different between the different places. it'd be nice if that could be updated to avoid a regression here
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 agree with the renaming and type usage. There is a problem with Vite's type definitions for their config, but there will be a correction in the next patch release. Also, a lot of changes already have been made to dev/index.js in #1572.
I think we need to hold off at least until the next Vite patch release and the next SvelteKit patch release.
I'm leaving for the US on 6/18, returning on 7/14, and should have a computer available.
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.
If you want to just do the renaming now and then merge this that'd be fine and we can add the Vite types later
I think another con is would be that Vite's option would then be unused or there'd be two places to specify it. I'd probably just leave it as is because of that |
🦋 Changeset detectedLatest commit: 1076db3 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@JBusillo it looks like the lint check is failing |
Ben -- please hold off the review. It seems like #1572 is preventing sending key/cert options to Vite. It's preventing me from testing:
@johnnysprinkles -- could you verify if your changes are preventing the user from specifying vite.server.https.cert and vite.server.https.key options? You can refer to my test project. I committed this just so johnnysprinkles has something to work with. I'll fix the lint error when I do my (hopefully) final commit. |
I can’t take a look at the moment but I might have caused a regression, I
suggested in the PR to only consider plain objects where constructor is
Object but didn’t get feedback on that. I can look tonight.
…On Wed, Jun 16, 2021 at 3:06 PM Joe Busillo ***@***.***> wrote:
Ben -- please hold off the review. It seems like #1572
<#1572> is preventing sending
key/cert options to Vite. It's preventing me from testing:
***@***.***:~/Projects/test-1659$ npm run dev
> ***@***.*** dev
> svelte-kit dev
The value for kit.vite.server.https.key.toString specified in svelte.config.js has been ignored. This option is controlled by SvelteKit.
The value for kit.vite.server.https.key.toLocaleString specified in svelte.config.js has been ignored. This option is controlled by SvelteKit.
The value for kit.vite.server.https.cert.toString specified in svelte.config.js has been ignored. This option is controlled by SvelteKit.
The value for kit.vite.server.https.cert.toLocaleString specified in svelte.config.js has been ignored. This option is controlled by SvelteKit.
> The "options.cert" property must be of type string or an instance of Buffer, TypedArray, or DataView. Received an instance of Object
@johnnysprinkles <https://github.com/johnnysprinkles> -- could you verify
if your changes are preventing the user from specifying
vite.server.https.cert and vite.server.https.key options? You can refer to
my test project <https://github.com/JBusillo/test-1659>.
I committed this just so johnnysprinkles has something to work with. I'll
fix the lint error when I do my (hopefully) final commit.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1662 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHYF4WWQTUKXF4BPMPTHZ3DTTEOADANCNFSM46NITMGQ>
.
|
https_options.key = user_config.server.https.key.toString(); | ||
https_options.cert = user_config.server.https.cert.toString(); | ||
if (key && cert) { | ||
https_options.key = key; |
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.
Am I reading this right? It looks like a no-op to me, since you've destructured key and cert out of https_options
, then you're setting those again on the same object you destructured out of.
You can mark it as a draft and take it out of draft mode when you're ready for review |
@benmccann - I don't think I have the required access to change the PR to a draft -- This link says "Any user with write access to the repository can convert a pull request to a draft pull request.". |
You should have access. There's a link that says "Still in progress? Convert to draft" under the Reviewers heading on the right hand side of the page |
I don't get that option. But, dummdidumm did it for me. Here's what I see on the left side of my PR: Screenshot |
Well that option is no longer there since it's already been clicked 😄 Now instead there's a "Ready for review" button between the comments and CI checks |
I forgot to commit my local repository before I left on my trip, so I'll have to wait until my return on July 14. Since this isn't a milestone issue, I don't see too much urgency. I'll have to merge johnnysprinkles changes into it, retest, commit and request a review. |
@JBusillo are you ready to revisit this PR? |
@benmccann Yes, my return was delayed by a week, and I'm getting settled back in. I have some upstream merging to do, along with some coordination with Johnny Sprinkles, which I'll initiate via a separate message. |
@benmccann -- I messed up my repository big-time. There were so many other changes to the modules I was working on, that I thought I could start fresh. I have notes and had saved all code changes for this PR, but everything is out of sync. I'm closing this, and will re-open it -- If I don't have access to re-open, I'll need some help/advice. Here goes..... |
@benmccann -- I can't re-open it. I had deleted the fork, since I wanted to "start over" with a fresh copy of master. Please advise. Thx. |
I can't reopen either since the fork is deleted. You will just have to copy/paste any code from here to your new branch. To avoid this in the future, make sure you are developing code on a branch. Then you can sync your master against the SvelteKit master ( |
Got it. I opened up a new PR. The old PR references the new PR, and vice versa. The new PR is set up as a draft for the time being. I just re-applied my code changes, and will do testing tomorrow. There's been a lot of code restructuring in the past 3-4 weeks! |
just a heads up - I don't see any code on the new PR |
I plan to commit the code when I'm done with local testing. I wanted to create the PR immediately to document the closed and open PR's. But, thanks for the heads up. |
Fixes #1659.
This PR was clobbered due to my error. It has been replaced by PR #2027.
The dev server passes the vite options (config.kit.vite) when creating the http(s) server. This is functioning correctly.
The preview server passes the kit options (config.kit) when creating the http(s) server. This is not functioning correctly.
In preview mode, when the user specifies a cert/key pair, the cert/key pair is ignored, since the logic is looking for the option in the wrong place. Instead, Kit will generate its own cert/key pair. You can observe this by examining the certificate details within the browser.
This change aligns where the dev and preview modes look for a user-specified cert/key pair.
For reference, here is an example of a user-specified cert/key pair in
svelte.config.js
Before submitting the PR, please make sure you do the following
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpx changeset
and following the prompts