chore(pre-commit): test:prep on package-lock.json change

[legobeat]

Changes in package-lock.json often result in fixture policy changes.

This runs test:prep as part of git pre-commit hook if lockfile is changed.

Related

• ci: fail if working tree is dirty #721
• chore(ci): fail if any VCS files changed #825

[boneskull]

This won't actually add any changed policy files to the commit, if that's what you wanted to happen. I don't think we want to do that, do we? This also won't tell the developer that "hey, some policy files changed..." until next time they run git status. By then, it might be running in CI already, and breaking because files changed in VCS (eventually; #825).

I feel like we might want to take a step back and ask why we keep updating these policy files in the first place.

Why would a change to our package-lock.json cause the policy in a fixture to update? Are the tests (usually this is browserify) resolving things they shouldn't? It doesn't seem like proper isolation.

[boneskull]

I guess I see why the file in #988 gets updated; that seems to have to do with hoisting. Still, I can't shake the feeling that the policy gen should not be so sensitive to the structure of node_modules. Maybe it's not really possible to do it any other way, or maybe it's like that for a reason that I don't understand.

[legobeat]

This won't actually add any changed policy files to the commit, if that's what you wanted to happen. I don't think we want to do that, do we?

Oh, this is indeed what I was aiming for. Either that or throwing in case of changes. How to get there?

And yeah, for now I think we need to keep these synced in git, despite the churn.

[boneskull]

To add, you'd have to do && git -A <files-expected-to-change>

[boneskull]

@legobeat

And yeah, for now I think we need to keep these synced in git, despite the churn.

Why?