Re: [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

From: Date: Thu, 27 Jun 2024 20:03:30 +0000
Subject: Re: [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-123959@lists.php.net to get a copy of this message
On Thu, Jun 27, 2024 at 4:31 PM Michael Morris <tendoaki@gmail.com> wrote: > > >> 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. > Perhaps my point here wasn't so obvious. I wasn't talking about Composer making drastic changes to accommodate this, I was only merely mentioning Composer being used to provide something like the following: ```composer.json { "require": { "php": "^8.2" .... }, "php-modules": { "@packages": "./packages", "@utilities": "./tools/utilities" .... } } ``` Then whenever there's a import Foo from '@packages/Foo.php', the notation @packages would be replaced by the packages folder. This is equivalent to Vite resolve.alias https://vitejs.dev/config/shared-options.html#resolve-alias -- Marco Deleu

« previous php.internals (#123959) next »