-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
--https fails if package name contains organization "@" #10840
Comments
I'd bet this is due to how the auto-generated dev server ssl certificates are named, see gatsby/packages/gatsby/src/commands/develop.js Lines 250 to 259 in 253580a
Edit: nice work isolating the repro steps! |
So, I went and actually did a little more testing (talk about a reason to mess around with my personal website!). I tried a couple different values in the "@pqt"
"pqt"
"@pqt/website"
"austinpaquette.com"
So my takeaway is that I was actually wrong, the organization name (specifically the @) character is causing the issue. To be fair, having the organization name in the package manifest for a gatsby site is a niche case. |
Description
For the longest time when I ran
gatsby develop --https
on SiteA, it ran fine. But when I ran it on SiteB it would fail. I could never figure out what was causing it and just always assumed it was an issue with my machine because it was seemingly hit or miss.Well I recently renamed a repo (including
package.json
) and all of a sudden the SSL started to fail!Oh boy, an isolated case!
Steps to reproduce
Run
gatsby develop --https
on a gatsby site with thepackage.json
name attribute either:@organization/repo
orFailing happened when I had the organization and a domain as part of the package manifest name field. IE:
Expected result
Normally I would expect it to run fine.
Actual result
Environment
Epilogue
When the configuration name was returned to
organization-website
the SSL ran fine. So I'm not 100% certain if it's caused by the organization namespace (which out of the gates I doubt) or if the domain name is causing the issue (which is the way I'm leaning).I don't have time to do a deep dive right this moment, but wanted to post this both for input and accountability for this evening.
I don't think it's necessarily a bug, but if it's truly a persistent issue, something in the documentation outlining this caveat may prevent some headaches in the future.
The text was updated successfully, but these errors were encountered: