Hi Michael, pon., 1 lip 2024 o 01:18 Michael Morris <tendo...@gmail.com> napisał(a):
> ... > Applications > > The application is the root package. It is the package that imports to the > root namespace. When PHP is asked to parse a file it will look for a > `.php-packages` folder, first in the current working directory then in > parent directories. If it doesn't find one, business as usual. If we do > find one we follow its directives about setting up an application > environment. > > The `.php-packages` folder is where PHP will put package related code for > the application at hand. Code written explicitly for these changes will > also put their package related files there - composer's vendor directory, > composer.json, composer.lock, and so on - rather than putting those files > in the site root. The folder is hidden to prevent web servers like nginx or > apache from serving the files directly in any way. > First, you use the term Application then Site - decide. Not all PHP applications are HTTP Applications, consider consumers, cron tasks other daemons, these don't need the existence of either Nginx or Apache. Not all PHP HTTP Applications expose files to Nginx or Apache - most of these I know like Rest API give ZERO access to any application file to Nginx or Apache. > The .php-packages directory will have a configuration file called > `php.mod`. This tells the parser: > You propose to move `composer.json`, `composer.lock`, and `vendor` into a hidden folder with no good reason which simply adds more confusion. > Let's look at what such a file might look like for Drupal. For the moment > I'm going to use go.mod's syntax. The final syntax to be used, be it ini, > yaml, toml, json, is a discussion for another time. The part to focus in on > here is what type of information do we need. > > package Drupal > > php 10 > > registry //packagist.org/packages composer > > init ( > composer install > ) > > require ( > ./vendor/autoload.php > ) > > imports ( > //getcomposer.org/composer.phar > ) > This looks like a completely new file format which simply makes interoperability harder, consider tools like GitHub Dependabot, PHPMetrics or other tools that analyze dependencies - what you propose requires implementing a parser in userland or other languages the tool uses. > The directives do the following: > ... > * init is the command(s) to run before the application is started for the > first time. > What is the use case for it I don't get it. Many PHP Applications are distributed as a container image with all dependencies already included. How would it work with multi-threaded environments, which thread would be responsible for running init? How do you solve concurrency problems then? > If this theoretical version of Drupal moves its composer.json and > composer.lock files into `.php-packages` then the autoloader doesn't have > to be required in the index.php file. Also, the application can be started > without running `composer install` > `index.php` is just a common name for PHP HTTP Applications for modern frameworks like Symfony and others that one lays in `public/` folder as an entry point, often this is the only file in this directory. If I understand your idea correctly you'd like a couple of I/O operations on the filesystem to find the `.php-packages` directory in CWD else if not in the parent directory and so on rather than directly pointing where it is, right? Cheers, Michał Marcin Brzuchalski
