Description
Feature Request
Q | A |
---|---|
Package | no |
New Feature | no |
BC Break | yes/no |
Introduction
League uri packages are made up of three (3) packages:
uri-interfaces
: contains contracts and utility classes to perform primitive process around URIuri
: contains concrete classes to handle complete URI and URI templates and depends onuri-interfaces
uri-components
: contains concrete classes to handle URI components and depends onuri
.
Having the contracts being defined on uri-interfaces
makes the dependency a bit too complex to decouple. For instance the uri
package does not depend nor does it requires uri-components
interfaces. Having those interface being loaded when requiring the uri
package make little sense.
Using the same argument the uri
package does not require the PSR-7
interfaces. The package provides a PSR-7 UriInterface
implementation. But that implementation is optional and is not a requirement for the package to work. So putting the PSR-7
and PSR-17
requirements in the suggest
section of the composer file seems reasonable. If compatibility with PSR
interfaces is a requirement explicitly requiring the extra package is a better option. It makes the dependency clearer and cleaner from a developer POV. The goal of this feature is to
- reduce the dependency tree
- makes it more clearer the goal of each separate packages.
We have two proposals:
Proposal 1:
- We remove all interfaces from the
uri-interfaces
packages which will only contains utility classes. - We move all the interfaces related to URI processing in the
uri
package. - We make the PSR-7/PSR-17 interfaces optional for the
uri
package. - We move all the interfaces related to URI component processing in the
uri-component
package. - We make the PSR-7/PSR-17 interfaces optional for the
uri-component
package.
The consequences:
- Introduce a BC to the
uri-interfaces
which will be bumped to v8. uri
dependencies stays as isuri-components
dependencies stays as isuri
anduri-components
will only be bump to a minor version v7.5.
Issues/Open questions:
- The current subsplit tool used in
uri-src
is unable to handle 2 major versions release at the same time. - The
UriAccess
interface uses the PSR-7UriInterface
in a union type for a return type. Is that affected by having PSR-7 classes optional inside theuri-package
?
Proposal 2:
- We create a new package
uri-helpers
which will only contains utility classes. - We move all the interfaces related to URI processing in the
uri
package. - We make the PSR-7/PSR-17 interfaces optional for the
uri
package. - We move all the interfaces related to URI component processing in the
uri-component
package. - We make the PSR-7/PSR-17 interfaces optional for the
uri-component
package.
The consequences:
uri
will now depend only onuri-helpers
uri-components
dependencies stays as is- the
uri-interfaces
package is deprecated (ie does not receive any updated and will still be requested and installed when using older version of uri version. - all packages are bumps to
7.5
(includinguri-helpers
)
Issues/Open questions:
- Should we remove from the monorepo
uri-interfaces
to be sure it has been deprecated and no longer received automatic update. We still need to keep it in line in case of security issue with the newuri-helpers
package. - Since we changed dependencies for
uri
in between version can this be considered as BC break for theuri
package or not ?
According to this issue it does not: Version after dependency changes? semver/semver#148 - The
UriAccess
interface uses the PSR-7UriInterface
in a union type for a return type. Is that affected by having PSR-7 classes optional inside theuri-package
? uri-helpers
will conflict withuri-interfaces
normally the conflict should be minimal on updateuri-interfaces
package should be replaced byuri-helpers
. A conflict can only arise if someone did require only theuri-interfaces
and then later on requires a version higher than 7.4 of any other package. But this can be solve by either removinguri-interfaces
or by installinguri-components
.
Future scope
Once the Interfaces have been moved to their appropriate package we should question their utilities
and if they should be removed/replace/split or if we should add more. Those changes should be examined in a context of a major BC break and for inclusion in the next major release for the library.