[1.x] Auto detect Valet / Herd TLS certificates

[timacdonald]

This PR adds:

• Valet / Herd certificate auto-detection (✨) and makes it the default for upcoming 1.x release.
• Ability to opt-out of auto-detection detectTls: false.
• CLI output to indicate when the Valet / Herd certificate is being used (when known).

Assume everywhere "Valet" is mentioned that it also applies to "Herd".

This PR allows teams with a mixture of Valet and non-Valet users to configure TLS certificates, without adding additional configuration.

The following standard Laravel plugin config supports both use-cases:

import fs from 'fs'
import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel({
            input: ['resources/css/app.css', 'resources/js/app.js'],
            refresh: true,
        }),
    ],
});

For Valet users, as long as a Valet certificate is found it will be used. Valet certificates are "guessed" in the same way they currently are.

1. $CWD is used as the host.
2. TLD is resolved from the Valet config.

For non-Valet users, you may specify the path to TLS certificates with the existing environment options.

VITE_DEV_SERVER_KEY=/path/to/key
VITE_DEV_SERVER_CERT=/path/to/cert

CLI output

We now output on the CLI when Vite certificates are in use. This will help users know when the Valet certificates have been auto-detected, etc.

The valetTls option now has the following options.

laravel({
  // ...

  // Auto-detection.
  // - Host is guessed via convention.
  // - Missing certificates are ignored.
  // _

  // Explicitly use Valet certificates.
  // - Host is guessed via convention.
  // - Errors are thrown when missing certificates. 
  valetTls: true,

  // Explicitly use Valet certificates.
  // - Host specified is used.
  // - Errors are thrown when missing certificates. 
  valetTls: 'tim.dev',

  // Opt-out of auto-detection.
  valetTls: false,
}),

[innocenzi]

This would be amazing, except for the way the host is resolved. My opinion is still that .env is better suited for this task. Consider the following scenario:

• A backend repository exists, it's an application that powers two brands
• Teammate1 clones backend locally at ~/Code/<brand1-name>
• Teammate2 clones backend locally at ~/Code/backend
• Both teammates use Valet

In this situation, even if Teammate1 sets APP_ENV to backend.test, the Valet certificates will not be found because of its directory name. It will work fine for Teammate2.

To fix this issue, vite.config.ts would need to be altered, just because of one of the developer's environment.

Alternatively, resolving the host via the working directory can be done as a fallback if .env is still at http://localhost (or at a value for which no certificate can be found), if that was your concern.

(I still think valetTls shouldn't be a configuration option, or at least that without using it, the scenario above should also be handled.)

I really like your addition to the CLI output. Looks pretty nice and it's useful.

[jessarcher]

Hey @innocenzi,

You're correct that we're concerned about APP_URL not being set correctly, but we're also concerned that it's not used by Valet to determine the link name or certificate location either. It just happens that it should match when configured correctly.

We prefer the working directory because that's what Valet uses by default. For cases where the Valet link name has been customised, the valetTls option can be used to pass the custom hostname. I can see how this might be an issue with your scenario, but I'm not sure how common it is, and it can be solved with some additional code in the team's vite.config.js.

Having said that, I'd love it if the auto-detection could handle custom link names.

I don't have a Mac and haven't used Valet, but from what I can tell, the valet link command uses symlinks to wire things up, making them effectively the source of truth. I'm wondering whether we can read the symlink name(s) pointing to the working directory to determine the hostname that Valet is using. I imagine we'd still need to fall back to the working directory name to handle valet park.

If that doesn't work out, I'm not completely opposed to using APP_URL as long as we also check the working directory.

[innocenzi]

It just happens that it should match when configured correctly.

I understand the concern and that technically, the semantics don't match — however, in practice, this is the perfect fit for this option, I would argue.

If that doesn't work out, I'm not completely opposed to using APP_URL as long as we also check the working directory.

I think this would be the perfect compromise, if the solution above doesn't work.

[innocenzi]

@timacdonald it's been a while, with the support or Herd now I thought this would be a good time to follow-up?

[timacdonald]

@jessarcher and I have started talking about this again. We will circle back to it shortly and get things moving, whichever way.

[timacdonald]

Will revisit this PR tomorrow and see if we can get it into shape for the 1.x release.