Ability to define custom renames for single package

[danieliser]

Would be nice if we could replace parts of a package namespace along the way.

Currently extras.mozart.packages accepts array of strings, I'm thinking it could be configured to accept objects as well

"packages": [
  "pimple/pimple",
  { 
    "name": "company/package",
    "replace_namespace: [ "\\Company\\Packages", "" ]
  }
]

In this way you can customize the handling of each package with various modifiers, such as string replacement in a namespace.

Still toying with how that gets implemented on the backend, but happy to proof of concept it.

[coenjacobs]

Can you give me a little more information on the use case for this? My first impression is that this is beyond the scope of what Mozart should do, but I could be wrong. Please convince me. :)

[danieliser]

@coenjacobs So this library does 99% of what I'm discussing already. It searches for a namespace and replaces it with a prepended namespace. That is, it does S&R very effectively on namespaces.

What I'm proposing is that you offer a little flexilibility in the search & replace, specifically the replace in my use case.

Just for example

namespace Company\Package;
class Container extends \Pimple\Container {}

Now I require that package in another project of the Company.

This project uses something like namespace Company\ProjectA;

So when mozart replaces things, it comes out as namespace Company\ProjectA\Company\Package which makes little to no sense when working with it in our own code base.

What I'd prefer is to change the Replacers replace string for this particular package with '' nothing, thus making is so I can simply call new Company\ProjectA\Container();, or alternatively shorthanding it at least to something more appropriate like 'UtilsorBootstrap` or similar.

I could come up with a few more use cases, but I quickly hit this once I started breaking our code into smaller reusable packages last week after finding mozart and deciding we should head this direction.

In general you could rename packages entirely in this way as well, while still maintaining the full link to their original source for easy updating via composer & attribution.

[coenjacobs]

Very valid use case, @danieliser, consider me convinced! This is actually one of the issues with Mozart I still had in the back of my mind, but hadn't connected the dots that you meant the same. I'd be very open to an implementation (or proof of concept) of this. Some things to keep in mind, though, that I think need to be accounted for:

• This specific replace string, also needs to be applied to all dependencies of that same package. What would happen if I want a specific replace for package A, but package A and B both require package C?
• By default, Mozart write all the files in their respective directory structure in the same parent folder (/Dependencies/ for example). According to the PSR-4 specification, this needs to be in the namespace as well (as those follow the directory structure). Should you be able to specify a unique target directory, in addition to a specific namespace replacement, then?

[danieliser]

@coenjacobs -

Good questions.

Off top of my head:

• I assume what you mean by child packages, would be pimple/pimple from the example I gave, in which case would there be a hard requirement for us to replace child packages of Package A, or could it just ignore those and put them in where the defaults were going anyways? Not 100% sure the logistics just yet.
• That does make since, but in my case I'd be just as happy to have a /Dependencies/Bootstrap folder as well. So I could be convinced either way. On the side of forward thinking though I'd err on the side of yes, we should probably consider allowing the definition of a custom output directory as well, but my concept of using a config object in place of string above supports that concept at least in terms of adding a new parameter.