Closes #388

Question: Should this warn if using the --include-deps flag when not using --scope or --ignore? The resulting build will be identical, its just misusing a flag. Happy either way. 👍

The second Adds docs for --include-deps flag in readme commit was to force appveyor to rebuild as it is strangely failing to install npm itself, still seems to be failing.

Anyone have any idea why that might be? It says it's a permission error when trying to rename a file and to re-run it as an admin.

EDIT: Ran a clean branch with no issues in appveyor -> no problem
Reran this branch a third time -> no problem.

Appveyor seems to be a little flakey with npm 0.12

Playing with this a bit more locally, I'm wondering if this should also include dev dependencies? At the moment I just manually bootstrap those using the --scope flag because there isnt too many.

Anyone have any opinions on this? Happy to add it.

I will definitely add the devDependencies at some point, its bitten me a few times using it locally now :P

I think it's a good idea to add devDependencies to --include-deps. That way it works as users expect it to work.

Hmm, --include-deps is ambiguous in certain commands I think. Can you rename it to --include-filtered-deps or something similarly descriptive?

@thejameskyle It's not for filtered deps though, it's for transitive deps.

--include-transitive-deps maybe? Bit verbose, but I'm only going to wrap it in scripts anyway. I should hopefully have time to rebase, rename and add the dev dependencies this week/weekend.

lol maybe --include-filtered-deps-deps

--bootstrap-deps maybe? Shorter and more descriptive/less ambiguous

So the original idea of --include-filtered-deps was to mean include the deps that were filtered out --scope and --ignore.

Happy to go with --include-filtered-deps. Tried to make the change today but I have a feeling im stuffing up this rebasing... Going to do it after #386 is merged so I can be sure this is right.

Super simple fix, just need to change the addDependencies function to use Object.assign({}, pkg.dependencies, pkg.devDependencies)

@gigabo Could you take a look at this one as well when you have time?

This one is rebased on #386 and should be ready as well. It's pretty required to make #386 useful.

@lukebatchelor Please rebase this when you get a chance now that #386 has landed in master.

Super weird, I did rebase on #386 and double checked the git log to make sure they had the same commits. Updating now

Oops, sorry. Got pulled away yesterday, should be good to go @gigabo
👍

Another thought on this topic (hopefully not derailing the PR too much in the process): I think this would be really valuable for all tasks to have, much like your filtering changes. Use case: lerna run build --scope foo --toposort --include-filtered-deps. Combined with #412, which I hope I get to today, this would allow me to rebuild foo and all of its dependencies in one shot in the right order (I have a Typescript project, so ordering matters, but a full rebuild of dependencies should be useful for non-Typescript projects too). This is very powerful, and likely has other usages that I haven't though of as well.

@gigabo Could I get some eyes on this when you've got time? 👍

Hi @lukebatchelor yep, just getting back from the holidays. Will take a look! 👀

Quick question: would it make sense to change this to --include-dependencies'? I envision that at some point we might want a --include-dependents flag and "deps" could be either.

Use case for --include-dependents would be to quickly install and run tests for any package that uses a package you're modifying.

@spudly it was changed to --include-filtered-deps recently. Do you think this could still have be confusing?

I'm with @spudly on this: better to be entirely explicit, since it doesn't save many keystrokes that often anyway (so: --include-filtered-dependencies). Full disclosure: I was also thinking about an --include-(filtered?)-dependents flag (reason being that from my previous comment, it would be awesome to be able to automatically select dependents of my package for rebuilding to make sure things aren't broken).

@lukebatchelor & @seansfkelley,

Yes, I do still think we need to explicitly call it --include-filtered-dependencies. I know it's long, which is annoying, but this way users know exactly what is going to happen without searching through the documentation, and it leaves room for similar flags down the road.

My vote is for --include-filtered-dependencies so that @seansfkelley or someone else can later add --include-filtered-dependents.

This looks good to me.

As for deps vs dependents I don't see that as a big issue. deps is a common short form of depencies. Don't really see it used for dependents much. Not opposed to the long form if others feel strongly.

Thanks for your patience @lukebatchelor, and for the nice clean change set. 👍

Sweet, well I'm happy with either as well. Personally I prefer deps because I spell dependency wrong approximately 100% of the time XD.

I'll leave the call up to you @gigabo / @seansfkelley ?

Everyone seems to be ambivalent, so I would err on the side of being explicit and just make it wordier. Reasonable?

Sorry for the delay! Just managed to get some time to do this. Will rename this morning.

@gigabo When you're ready 👌

Thanks @lukebatchelor!

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.