https://github.com/petermcd/dependency-visualiser

Package to help visualise PHP package dependencies
https://github.com/petermcd/dependency-visualiser

Last synced: 5 days ago
JSON representation

Package to help visualise PHP package dependencies

• Host: GitHub
• URL: https://github.com/petermcd/dependency-visualiser
• Owner: petermcd
• License: gpl-3.0
• Created: 2019-05-08T23:41:18.000Z (about 7 years ago)
• Default Branch: master
• Last Pushed: 2022-09-22T20:33:18.000Z (almost 4 years ago)
• Last Synced: 2025-02-17T03:44:26.421Z (over 1 year ago)
• Language: PHP
• Homepage:
• Size: 636 KB
• Stars: 0
• Watchers: 2
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

          
# Dependency Visualiser

With any modern PHP project, the number of dependencies can grow

almost exponentially. Keeping track can be a difficult task,

especially when those dependencies have a large number of sub

dependencies.

For example this package has the following explicit dependencies:

* php

* ext-json (php extension)

* phpstan/phpstan (dev)

* infection/infection (dev)

* rockprofile/dependency-visualiser-neo4j (dev)

however, after composer does its thing the dependencies grows:

!['Project Dependencies'](images/dependencies.png "Project Dependencies")

From 5 explicit dependencies, when considering a dev environment

we now have 65 dependencies ranging from composer packages, PHP

extensions and the language itself.

Dependency visualiser is a tool that enables you to map

the dependency tree of a PHP project.

## Requirements

The package currently reads each composer file. It will adhere 

to the vendor-dir parameter of the composer file.

A basic storage engine for Neo4j exists on composer

(rockprofile/dependency-visualiser-neo4j). As long as 

StorageInterface is implemented you can use any storage mechanism.

## Current Limitations

The biggest current limitation is that the script does not identify if

there are conflicting required package versions. Although composer

should complain if this does occur it would be handy for the script to 

identify this also.

It would also be good for the script to identify the minimum version

required for each dependency in the event that multiple sub dependencies

require the same package.

## To Do

* Identify the minimum available version of a dependency.

* Implement a parser for other package managers such as NPM.

* Modify the package to use the lock file if available falling back to

individual files if necessary. This will help ensure that version numbers

are logged. A lot of packages do not have versions in the Composer.Json

* Separate the content of Package to another package so that other packages 

can use them properly.