Skip to content

URI Toolkit roadmap to v8 and beyond #137

Open
@nyamsprod

Description

@nyamsprod

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 URI
  • uri: contains concrete classes to handle complete URI and URI templates and depends on uri-interfaces
  • uri-components: contains concrete classes to handle URI components and depends on uri.

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 is
  • uri-components dependencies stays as is
  • uri and uri-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-7 UriInterface in a union type for a return type. Is that affected by having PSR-7 classes optional inside the uri-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 on uri-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 (including uri-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 new uri-helpers package.
  • Since we changed dependencies for uri in between version can this be considered as BC break for the uri package or not ?
    According to this issue it does not: Version after dependency changes? semver/semver#148
  • The UriAccess interface uses the PSR-7 UriInterface in a union type for a return type. Is that affected by having PSR-7 classes optional inside the uri-package ?
  • uri-helpers will conflict with uri-interfaces normally the conflict should be minimal on update uri-interfaces package should be replaced by uri-helpers. A conflict can only arise if someone did require only the uri-interfaces and then later on requires a version higher than 7.4 of any other package. But this can be solve by either removing uri-interfaces or by installing uri-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.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions