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

Added options to filter production / development dependencies (supersedes #19) #35

Open
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@jkphl

jkphl commented Jan 8, 2017

I added the options

  • --no-dev to exclude development dependencies from the graph,
  • --dev-only to visualize the root package and its dev dependencies only.

This PR supersedes #19 which didn't work correctly for me. While it deleted the vertices from the root package to its immediate dev dependencies, the production dependencies of dev dependencies still kept them in the graph (resulting in multiple root nodes, e.g. the root package plus PHPUnit).

Please consider merging soon (before the package base changes again). Thanks!

@jkphl

This comment has been minimized.

jkphl commented Jan 16, 2017

@clue Any updates on merging this?

@clue

Thanks for filing this PR, very much appreciated 👍

At first sight, I like the new features and the implementation seems to be okay, too 👍

Unfortunately, this is currently very hard to review because it addresses multiple things at once and does not add any tests to verify the correct behavior.

I'd love to get these features in, so I'd like to ask you to break this up into multiple, smaller PRs to ease review and speed up getting this in :shipit: Thanks!

@jkphl

This comment has been minimized.

jkphl commented Jan 19, 2017

@clue Thanks for your efforts. However, a couple of things:

  • I'm sorry for that, but my current workload is extreme and I won't be able to further work on this anytime soon. In case you're not able to merge this right away, I'll probably have to stick to my fork (which is working perfectly fine for me). Of course, anyone else could jump in as well.
  • The PR adds two new options which are directly related to each other. I don't see a reasonable way to separate them into two PRs that are truly meaningful on themselves.
  • The two new options do nothing else but alter the content of the graphs. None of your current tests evaluates the content of the graphs in any way. Shouldn't you add content evaluation tests first before testing any modifiers?
@clue

This comment has been minimized.

Owner

clue commented Jan 19, 2017

I'm sorry for that, but my current workload is extreme and I won't be able to further work on this anytime soon. In case you're not able to merge this right away, I'll probably have to stick to my fork (which is working perfectly fine for me). Of course, anyone else could jump in as well.

No worries, we all know that feeling :-) Let's hope anybody (perhaps your future you) finds the time to pick this up again 👍

The PR adds two new options which are directly related to each other. I don't see a reasonable way to separate them into two PRs that are truly meaningful on themselves.

IMHO both options provides value on their own, but I understand YMMV 👍 I agree this is not exactly a killer here, but this would certainly ease reviewing this.

The two new options do nothing else but alter the content of the graphs. None of your current tests evaluates the content of the graphs in any way. Shouldn't you add content evaluation tests first before testing any modifiers?

Yes and yes :-) The current implementation is rather trivial, but I'll look into filing some tests for this soon-ish 👍 The features you've added add some non-trivial complexity, so I'd argue it's about time to add some tests :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment