Hoping that someone can clear something up for me about how the affected command is working. Currently say we have 2 libs
lib2 , lib1 imports lib2. If I change anything in lib2 then lib1 is affected (obviously) but if I update the spec file, and write more unit tests in the spec file for lib2 then lib1 is also affected. Is this by design? I feel like I should need to test lib1 again if I only updated tests in lib2 and I shouldn’t need to rebuild either (and anything that they depend on) if I only wrote more tests. Really in this case should the only thing I need to do is rerun tests for lib2? Am I thinking about this wrong? Or do I have a misconfiguration?
As far as I understand, affected evaluates every git change below the
root property of any lib/app; meaning, even if you were to change a readme file within that root, that lib will be considered “affected”
Hmm I wonder if that should/could be changed? Possibly by filtering out files that don’t have relevance to the code? Not sure if that is doable or a good idea though.
I may be wrong though… but I am like 92% sure
I am pretty sure you are right. And it uses changed paths from git
yes, it uses git changes to identify driectly affected libs and then uses the dep graph to identify inferred affected libs
Hmm, ok thanks!
|I think you could drastically reduce built/test/lint times locally and on CI if we could configure that to ignore certain regexes (or globs) for certain commands. Like when determining affected:build ignore `(spec||md) etc.|
but that would not work for your specific case that you provided
spec files is all .ts
ya but if build ignored files that matched
*.spec* then it would see changes on all .ts files except *.spec.ts?
but yes, I would not need to build an app, if only *.spec.ts files changed
is this something you guys would want? Or would is be better as a plugin that extends the affected commands?
I guess PRs are open :wink:
That they are! I am totally going to look into this, just one more thing on my list of projects…
maybe the effort is not worth it though… for the spec.ts case, how often does it really happen that you ONLY change spec files without touching the related ts files