Change IDE alias

Update flake

This was faulty

Include editorconfig

Fix generateAggregateRootId()

Updates

Ideally, I'd like to be able to require a package with composer and be able to do something like @dflydev as a ruleset. However, my little research shows it may be impossible.

The best example I've seen so far is here:

• https://github.com/mollie/php-coding-standards

I'd like to know how you can use Mollie's coding standards using this format:

$rules = [
    '@PER' => true,
    '@Symfony' => true,
    // ...
];


return (new Config())
    ->setFinder($finder)
    ->setRules($rules) // ...
    ->setRiskyAllowed(true)
    ->setUsingCache(true);

• Can we include an array in addition to a class name for setRules?
• Can we call setRules multiple times?
• We'd want to ensure we can easily override the rules inside this package... and that means the order is important.

Initial import

Initial import

Initial import

I do not think this is a good idea. Especially as PHP-CS-Fixer rules cannot be individually ignored. Imagine class with one readonly property. The class can be perfectly mutable class that is allowed to be extended by another non-readonly class.

If readonly class would be inherited by children, it would indeed cause potential issues. Could we make it configurable? For example, as I've learned more about php-cs-fixer, I'd imagine something like this could be part of the design? For example, default behavior would be to not offer to promote a class to readonly if it is abstract, but give the option to include those as well?

[

  // Default behavior ( ['even_abstract' => false] )
  'promote_readonly_class' => true,

  // Can be overridden to 
  'promote_readonly_class' => [
    'even_abstract' => true,
  ],

I've spent very little time thinking about naming, here, but hopefully this helps show what I'm suggesting. :)

Updates

@shengslogar I wonder if this is a simple order-of-operations issue? Can you try putting the unmodified favicon/robots directives before the root redirect/last directive?

location /some-valet-uuid-directory-path/ {
    internal;
    alias /;
    try_files $uri $uri/;
}

location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt  { access_log off; log_not_found off; }

location / {
    rewrite ^ "/Users/sheng/.composer/vendor/laravel/valet/server.php" last;
}

Since that root-level rewrite has last at the end, I'm wondering if those locations are being applied after the fact?

It looks like the way serveStaticFile works (https://github.com/laravel/valet/blob/d1967bbd0c61e528e47a79ed45556e58c2e614cf/cli/Valet/Drivers/ValetDriver.php#L137) is by doing an internal redirect to include that /some-valet-uuid-directory-path prefix.

Maybe it won't matter, but might be worth a try? Would involve not changing the "standard" way to silence favicon and robots without other weird side effects like serving the file with a 404 or NOT serving a file and still having a 200/204 response which would likely confuse people for the same reason.

Nginx is looking for a favicon.ico file at the root level. Instead, for Laravel projects, it should look in the public folder.

I'm not convinced this is correct. The location context, as I understand it, is already relative to a URL (location vs directory). I think that changing location = /favicon.ico to location = /public/favicon.ico only "works" because you're no longer specifying any special handling for favicon.ico. In other words, it's the same thing as removing the line entirely since you don't have anything in public/public/favicon.ico directory.

I'm not using valet a lot these days, but I still get notified about messages like this because I was dealing with it at one point. I did a quick google search and came up with the following:

https://stackoverflow.com/a/45562682

location = /favicon.ico {
  return 204;
  access_log     off;
  log_not_found  off;
}

It occurred to me that since location is sorta "virtual," what it's doing is slapping some additional metadata around the location that is in addition to the actual file on disk. I have no idea why nginx is both deciding based on this that it will return a 404 and then do the work to get the actual content from disk (wat?) but maybe it makes sense? If you are adding a location context maybe the assumption is that nginx should use the location context to derive most everything about that request from the location?

I wanted to see if there was a more complex return directive that could be aware of whether or not the file actually exists. The best I came up with was this:

https://github.com/vstoykovbg/nginx.conf-examples/blob/master/favicon.ico.md

location = /favicon.ico {
	try_files $uri =404;
	log_not_found off;
	access_log off;
}

This would look to see if the requested file exists and send a 404 only if it does not.

In short, it seems like we have a few options for how we could default this:

Assume everything is good to go and default to 200 or 204 or something

location = /favicon.ico {
  return 204;
  access_log     off;
  log_not_found  off;
}

Pros

• Doesn't pollute access log
• Doesn't pollute error log
• Doesn't return 404 to the client (ever)

Cons

• Doesn't return 404 to the client (ever) – this would mean if you don't have a favicon.ico, it might look to the browser like you do? Which could be equally confusing to having a 404 when the file does exist...

Check to see if the file exists and throw a 404 if not

location = /favicon.ico {
  try_files $uri =404;
  access_log     off;
  log_not_found  off;
}

Pros

• Doesn't pollute access log
• Doesn't pollute error log
• Doesn't return 404 if the file exists
• Does return 404 if the file does NOT exist

Cons

• Nginx will have to do the work to see if the file is there or not before it knows how to respond

Honestly, I think the last one, even though a bit "heavier", is probably the behavior everyone expects? It's what I expected for sure. I'd expect that we're telling nginx that for robots.txt and favicon.ico, we know those get asked for a lot, we aren't sure they actually exist, and we don't want to see them in the access log, and we also don't care if they are not there so do not bother showing me an error log about it.

I never got to where I was happy with this chicken or the egg problem. I came to the conclusion the best solution would involve writing a proper Twig/Markdown lexer/parser or something along those lines because whether you process one vs the other first hashadmajor impact on everything and it seemed like there was no good/sure way to handle it. :-/

I know for my own posts some combination of verbatim and breaking things out (like your {{ "${{" }} matrix.os }} fix) was used depending on which seemed less dirty at the time.

Add Typora