Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add --dev argument and behave similar to composer by ignoring development dependencies #2

Open
clue opened this issue May 16, 2013 · 8 comments

Comments

@clue
Copy link
Owner

clue commented May 16, 2013

The current behavior is to also visualize development dependencies. This should be changed to ignore them by default and add a new --dev argument flag which enables showing development dependencies.

@indeyets
Copy link

A bit more complex than that.

--dev should show development dependencies of the package itself. dev-dependencies further by tree should be ignored always

@clue
Copy link
Owner Author

clue commented Sep 13, 2013

A bit more complex than that.

Indeed, just analyzing this whole thing took me like an hour. The actual package information is parsed by jms/composer-deps-analyzer and I think we've encountered a few minor flaws. The following observations have been performed on a temporarily patched version and I'll file a few PRs in the next couple of days.

Considering the project "clue/graph" for example. If you happen to install it via "composer install --no-dev", its graph will look like this:
install-nodev

And alternatively, if you install it via "composer install --dev" (the default), its graph will look like this:
install-dev

So the behavior depends on whether the development dependencies are installed. And in my opinion this is what makes most sense, in order to display what is actually installed.

Even if "phpunit/phpunit" is not installed in the former case, it still makes sense to provide just the indication that it is a development dependency. One thing I'd like to change though, is to give an additional indication that it's in fact not installed (like semi-transparency).

dev-dependencies further by tree should be ignored always

Agreed, and I think this should already be the case.

Additionally, I think instead of adding a "--dev" option, it's probably better to add an "--no-dev" option instead, to mimic composer's current behavior. No matter how the root package is installed, its graph should then looks like this:
nodev

Any thoughts?

@shprink
Copy link

shprink commented Mar 28, 2014

mimicking composer's --no-dev option is a good idea. I do not have any idea how to make it happen but it is definitely a need :) +1

@clue
Copy link
Owner Author

clue commented Mar 28, 2014

@shprink, absolutely! I've opened a PR to support this in the underlying library just yesterday (schmittjoh/composer-deps-analyzer#9). I'll report progress in this ticket.

@shprink
Copy link

shprink commented Mar 28, 2014

Good to know thanks. At the moment I had to re-install temporary repo with --no-dev to get the right diagram.
Good job btw, you saved my day :)

@gimler
Copy link

gimler commented Nov 21, 2014

any news?

@clue
Copy link
Owner Author

clue commented Jun 6, 2015

any news?

Yeah, I've pushed an upstream PR (schmittjoh/composer-deps-analyzer#9), but haven't received any feedback so far.

Meanwhile, there's also a pending PR (#19) which implements this in our code base instead of pushing this upstream. I suppose any input is welcome :) Perhaps coordinate efforts and pick up either / decide on either PR? 👍

@GaryJones
Copy link

Not much to add, except a strong +1 for being able to ignore require-dev dependencies of my package and those of the require packages my package depends on.

@clue clue added this to the v1.2.0 milestone Oct 8, 2018
@clue clue modified the milestones: v1.2.0, v2.0.0 Mar 18, 2020
@clue clue modified the milestones: v2.0.0, v1.2.0 Dec 30, 2021
@clue clue modified the milestones: v1.2.0, v1.3.0 Oct 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants