--https fails if package name contains organization "@"

[pqt]

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 the package.json name attribute either:

• A) Containing @organization/repo or
• B) Containing a domain name

Failing happened when I had the organization and a domain as part of the package manifest name field. IE:

{
  "name": "@organization/organization.com"
}

Expected result

Normally I would expect it to run fine.

Actual result

error 
Failed to generate dev SSL certificate


  Error: Command failed: openssl genrsa -out /Users/austin/.config/devcert/@organization/organization.com.key 2048
  
  - utils.js:20 run
    [organization.com]/[devcert-san]/dist/utils.js:20:28
  
  - utils.js:10 openssl
    [organization.com]/[devcert-san]/dist/utils.js:10:12
  
  - utils.js:33 Object.generateKey
    [organization.com]/[devcert-san]/dist/utils.js:33:5
  
  - index.js:39 
    [organization.com]/[devcert-san]/dist/index.js:39:21
  
  - Generator.next
  
  - tslib.js:104 fulfilled
    [organization.com]/[tslib]/tslib.js:104:62
  
  - util.js:16 tryCatcher
    [organization.com]/[bluebird]/js/release/util.js:16:23
  
  - promise.js:512 Promise._settlePromiseFromHandler
    [organization.com]/[bluebird]/js/release/promise.js:512:31
  
  - promise.js:569 Promise._settlePromise
    [organization.com]/[bluebird]/js/release/promise.js:569:18
  
  - promise.js:614 Promise._settlePromise0
    [organization.com]/[bluebird]/js/release/promise.js:614:10
  
  - promise.js:694 Promise._settlePromises
    [organization.com]/[bluebird]/js/release/promise.js:694:18
  
  - async.js:138 _drainQueueStep
    [organization.com]/[bluebird]/js/release/async.js:138:12
  
  - async.js:131 _drainQueue
    [organization.com]/[bluebird]/js/release/async.js:131:9
  
  - async.js:147 Async._drainQueues
    [organization.com]/[bluebird]/js/release/async.js:147:5

Environment

  System:
    OS: macOS 10.14.2
    CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.5.0 - ~/.nvm/versions/node/v10.5.0/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v10.5.0/bin/npm
  Browsers:
    Chrome: 71.0.3578.98
    Firefox: 61.0.2
    Safari: 12.0.2
  npmPackages:
    gatsby: ^2.0.33 => 2.0.79 
    gatsby-image: ^2.0.25 => 2.0.25 
    gatsby-plugin-google-analytics: ^2.0.8 => 2.0.8 
    gatsby-plugin-manifest: ^2.0.12 => 2.0.13 
    gatsby-plugin-purgecss: ^3.0.0 => 3.0.0 
    gatsby-plugin-react-helmet: ^3.0.5 => 3.0.5 
    gatsby-plugin-sass: ^2.0.7 => 2.0.7 
    gatsby-plugin-sharp: ^2.0.16 => 2.0.17 
    gatsby-plugin-typescript: ^2.0.3 => 2.0.3 
    gatsby-source-filesystem: ^2.0.12 => 2.0.12 
    gatsby-transformer-sharp: ^2.1.9 => 2.1.10 
  npmGlobalPackages:
    gatsby-cli: 2.4.6

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.

[m-allanson]

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

	// Check if https is enabled, then create or get SSL cert.
	// Certs are named after `name` inside the project's package.json.
	if (program.https) {
	program.ssl = await getSslCert({
	name: program.sitePackageJson.name,
	certFile: program[`cert-file`],
	keyFile: program[`key-file`],
	directory: program.directory,
	})
	}

Edit: nice work isolating the repro steps!

[pqt]

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 package.json name field, I'll explain the results below:

"@pqt"

• Name contains illegal characters, logical, since NPM doesn't allow just the organization name anyhow.

"pqt"

• SSL was configured no problem.

"@pqt/website"

• Failed to generate dev SSL certificate. So it seems like the problem lies within the @pqt organization.

"austinpaquette.com"

• SSL was configured no problem.

---

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.