On Thu, Jun 27, 2024 at 2:11 PM Deleu <deleu...@gmail.com> wrote: > Who would build it is an extremely key aspect of making changes to PHP. > Ideas are hard enough to survive the RFC process when there's already an > implementation. Finding a sponsor to work on this would be the first step. >
Agreed. > > Given that ini settings are frowned upon nowadays, I think having a `<?php > declare(modules=1);` for the initial file might make the idea more likely > to pass a vote? Or maybe I'd even try to go one step further and say that > whatever file is being executed by SAPI (the first PHP file) could be > interpreted with a dumb lookahead. If the file has import / export syntax, > treat it like PHP Module, otherwise fallback. > MKS Archive already pointed out that even this is unecessary. Just let the landing file import the modules, even if that means it's a one line file. > > I'm not familiar enough with Javascript / Typescript ecosystem, but I've > only ever seen / used the ability to import using direct filepath. > In the clientside up until recently direct filepath was the only way. That changed with import maps https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap NodeJS has been doing something similar serverside for much longer with CommonJS requires, which predate by a good 5 years the ES6 mechanism. As a serverside language it now has to juggle both. The resolution path I sketched out is based on how NodeJS works. Can that be improved upon? Likely - it is confusing > The fact there's weird behaviors as result of trying to import a file and > suddenly a file all the way from `include_paths` or `php_modules` seems > like a no-go to me. I'd favor using only simple file path navigation and if > the file doesn't exist, error. > > Perhaps if the idea gains merit, Composer could offer something similar to > Vite where we can create an alias to a specific folder and then import > things like `from '@package/path/to/file`. > Composer would need a massive rewrite to be a part of this since it currently requires the file once it determines it should do so. If we do a system where import causes the parser to act differently then that alone means imports can't be dealt with in the same manner as other autoloads. > > >> This will of course require a package manager similar to composer to >> become part of core. However, composer will not be eclipsed as the import >> package manager (phppm?) is only concerned with user modules. These modules >> must explicitly export any symbols being fetched from them, whereas >> composer will continue to load files using require. >> >> Imports can also be done against directories >> >> ``` >> import foo from "mypackage" >> ``` >> >> In this case the parser will look for "mypackage/index.php" >> > > I'm not fond of this either. > > There will need to be a way to define the entrypoint php. I think index.php is reasonable, and if another entry point is desired it can be called out -> "mypackage/myentry.php" > ---------------- > > Overall, I think PHP has already reached the limit of surviving with only > PSR-4 and Composer. Single class files were a great solution to get us out > of the nightmare of `require` and `import` on top of PHP files. But more > than once I have had the desire to declare a couple of interfaces in a > single file, or a handful of Enums, etc. It seems like PHP Modules could > also address the issue with function autoloading and package-level > visibility. I like the idea but I'm a bit skeptical until we have some > buy-in from someone that could actually get this implemented. > That would be one of the larger hurdles, if not the largest.
