Dynamice $name, $vendor, $package replacement

[bpacholek]

Allows dynamic path replacements according to the package name (name and/or vendor).

For example in path: "./src/Provider/{$name|P}": ["providers/abc","providers/def"]

{$name|P} will be dynamically replaced by abc or def depending on the package installed. Flag P instructs the installer to make first character uppercase.

Supported variables: $package - full package name $name - if package name is in a format vendor/name (split by slash) then second part (name) will be used $vendor same as above but with vendor.

[mnsami]

hello @ideaconnect

Sorry I was on vacations, and I couldn't reply earlier :)

I see you want to have a dynamic directory creator according to the package name. I see the use case behind it, but can you make it less complicated with the Flag part? I mean we can directly follow the composer convention and the use the vendor / package_name as directory tree, the main purpose of this project is to give flexibility to composer consumers to download packages with any complexity.

What do you think?

[bpacholek]

hi @mnsami

Thank you for your response. I hope you had good time during vacation :+1:

the main purpose of this project is to give flexibility to composer consumers to download packages with any complexity.

and that is exactly what I want to achieve with the flags :).

Instead of for instance removing them I would even go further by extending the feature. Let me give you few examples:

If a developer wants a structure like: ./Sources/Providers/ and later folders with the name of the provider, yet repos are usually lowercase so if we would have two repos called:

provider/sample provider/example

He could set the composer like this: "./Sources/Providers/{$name}": ["provider/sample","provider/example"]

but this would end up with folders:

./Sources/Providers/sample ./Sources/Providers/example

why he would want the keep the naming convention with capital letters first. With my approach he can use the flag P to achieve that and have:

./Sources/Providers/Sample ./Sources/Providers/Example

which I believe is a valid use case. Furthermore I would add a separate flag or extend the existing to replace dashes etc. - for example if the repo is called:

provider/sample-provider

some developers will want it to be installed to:

./sources/providers/sample-provider

and some to:

./Sources/Providers/SampleProvider

Keeping the flags approach allows to define such replacements while using a set of repositories and dynamic rules.