## Summary
Hoists the `otter.LoaderFunc` closure in `GetUnCommonHeader` to a
package-level `loader` var, so it is allocated once at init time instead
of being re-created on every call.
This is a minor cleanup — the previous code created a new `LoaderFunc`
closure each time `GetUnCommonHeader` was called. While otter's
cache-hit path is fast enough that this doesn't show a measurable
difference in end-to-end benchmarks, avoiding the repeated allocation is
strictly better.
## What changed
**Before** (closure created per call):
```go
func GetUnCommonHeader(ctx context.Context, key string) string {
phpHeaderKey, err := headerKeyCache.Get(
ctx,
key,
otter.LoaderFunc[string, string](func(_ context.Context, key string) (string, error) {
return "HTTP_" + headerNameReplacer.Replace(strings.ToUpper(key)) + "\x00", nil
}),
)
...
}
```
**After** (closure allocated once):
```go
var loader = otter.LoaderFunc[string, string](func(_ context.Context, key string) (string, error) {
return "HTTP_" + headerNameReplacer.Replace(strings.ToUpper(key)) + "\x00", nil
})
func GetUnCommonHeader(ctx context.Context, key string) string {
phpHeaderKey, err := headerKeyCache.Get(ctx, key, loader)
...
}
```
## Benchmarks
Apple M1 Pro, 8 runs, `benchstat` comparison — no regressions, no extra
allocations:
| Benchmark | main | PR | vs base |
|---|---|---|---|
| HelloWorld | 41.81µ ± 2% | 42.75µ ± 5% | ~ (p=0.065) |
| ServerSuperGlobal | 73.36µ ± 2% | 74.20µ ± 3% | ~ (p=0.105) |
| UncommonHeaders | 69.03µ ± 3% | 68.71µ ± 1% | ~ (p=0.382) |
All results within noise. Zero change in allocations.
While continuing the work on #2011, I realized that constant
declarations have a problem when using `iota`. I mean, it technically
works, but const *blocks* we not supported which means that setting all
constants to `iota` as shown in the documentation was non-sensical, as
`iota` resets every time outside of const blocks.
So, this is between the bug fix and the feature. To me, it's a bug fix
as the behavior wasn't the one intended when creating extgen.
This one is interesting — though I’m not sure the best way to provide a
test. I will have to look into maybe an integration test because it is a
careful dance between how we resolve paths in the Caddy module vs.
workers. I looked into making a proper change (literally using the same
logic everywhere), but I think it is best to wait until #1646 is merged.
But anyway, this change deals with some interesting edge cases. I will
use gherkin to describe them:
```gherkin
Feature: FrankenPHP symlinked edge cases
Background:
Given a `test` folder
And a `public` folder linked to `test`
And a worker script located at `test/index.php`
And a `test/nested` folder
And a worker script located at `test/nested/index.php`
Scenario: neighboring worker script
Given frankenphp located in the test folder
When I execute `frankenphp php-server --listen localhost:8080 -w index.php` from `public`
Then I expect to see the worker script executed successfully
Scenario: nested worker script
Given frankenphp located in the test folder
When I execute `frankenphp --listen localhost:8080 -w nested/index.php` from `public`
Then I expect to see the worker script executed successfully
Scenario: outside the symlinked folder
Given frankenphp located in the root folder
When I execute `frankenphp --listen localhost:8080 -w public/index.php` from the root folder
Then I expect to see the worker script executed successfully
Scenario: specified root directory
Given frankenphp located in the root folder
When I execute `frankenphp --listen localhost:8080 -w public/index.php -r public` from the root folder
Then I expect to see the worker script executed successfully
```
Trying to write that out in regular English would be more complex IMHO.
These scenarios should all pass now with this PR.
---------
Signed-off-by: Marc <m@pyc.ac>
Co-authored-by: henderkes <m@pyc.ac>
Co-authored-by: Kévin Dunglas <kevin@dunglas.fr>
Allows doing something like this:
```caddyfile
watch "/app/{config,src}/*.{php,js}"
```
In the long term it would be nice to have pattern matching in the
watcher repo itself
This patch brings hot reloading capabilities to PHP apps: in
development, the browser will automatically refresh the page when any
source file changes!
It's similar to HMR in JavaScript.
It is built on top of [the watcher
mechanism](https://frankenphp.dev/docs/config/#watching-for-file-changes)
and of the [Mercure](https://frankenphp.dev/docs/mercure/) integration.
Each time a watched file is modified, a Mercure update is sent, giving
the ability to the client to reload the page, or part of the page
(assets, images...).
Here is an example implementation:
```caddyfile
root ./public
mercure {
subscriber_jwt {env.MERCURE_SUBSCRIBER_JWT_KEY}
anonymous
}
php_server {
hot_reload
}
```
```php
<?php
header('Content-Type: text/html');
?>
<!DOCTYPE html>
<html lang="en">
<head>
<title>Test</title>
<script>
const es = new EventSource('<?=$_SERVER['FRANKENPHP_HOT_RELOAD']?>');
es.onmessage = () => location.reload();
</script>
</head>
<body>
Hello
```
I plan to create a helper JS library to handle more advanced cases
(reloading CSS, JS, etc), similar to [HotWire
Spark](https://github.com/hotwired/spark). Be sure to attend my
SymfonyCon to learn more!
There is still room for improvement:
- Provide an option to only trigger the update without reloading the
worker for some files (ex, images, JS, CSS...)
- Support classic mode (currently, only the worker mode is supported)
- Don't reload all workers when only the files used by one change
However, this PR is working as-is and can be merged as a first step.
This patch heavily refactors the watcher module. Maybe it will be
possible to extract it as a standalone library at some point (would be
useful to add a similar feature but not tight to PHP as a Caddy module).
---------
Signed-off-by: Kévin Dunglas <kevin@dunglas.fr>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This PR:
- moves state.go to its own module
- moves the phpheaders test the phpheaders module
- simplifies backoff.go
- makes the backoff error instead of panic (so it can be tested)
- removes some unused C structs
