Great! Will look into it.
Message originally sent by slack user U717FXJ8HWK
It also caught some invalid values of enforce_* keys in our package.yml files 
Oh sweet 
Do you think you or your team would be interested in actually using the tool for local dev (e.g. continue to use ruby impl. in CI until this is stable)?
I’d understand if not (it’s experimental, complicated install, possibility of drift with packwerk causing extra toil).
Message originally sent by slack user U717FXJ8HWK
At first I thought it was a bug in Packs because Packwerk worked fine, but Packwerk just treated the invalid value as falsey :shrug:
Message originally sent by slack user U717FXJ8HWK
I think I’ll use it myself, not sure yet about the wider rollout, but that should also be possible. Since it’s not yet 100% compatible I believe, I’m not looking forward to all the support requests that might come
Message originally sent by slack user U717FXJ8HWK
Basically, I think I’ll test it for some time to gain some confidence in the tool first, then we can think of rolling it out (opt-in first, perhaps) to our engineers
Message originally sent by slack user U717FXJ8HWK
For CI we would also need the stale violation detection to work, as we use Danger to notify developers of stale violations, as they’re very annoying to deal with if it’s not your change that caused them
Message originally sent by slack user U717FXJ8HWK
Great progress overall! 
Message originally sent by slack user U717FXJ8HWK
I think hooking packs into the VS Code plugin would be amazing for productivity too
Yeah, I was just typing that!
Everything you say tracks! Hoping the first value this can deliver is helping folks run check and update more quickly. After, I plan to make the format compatible with the VSCode extension (i.e. you just configure what executable runs) so it provides faster feedback.
Thanks for the kind words and I appreciate your help and early adopter mentality 
Message originally sent by slack user U717FXJ8HWK
When it comes to distribution, I think we should copy what Sorbet does, which is to ship prebuilt binaries as Ruby gems 
But I guess it’s too early for that yet. Homebrew is unlikely to be available on Linux
Message originally sent by slack user U717FXJ8HWK
One more thing: how about using dashes in command names, e.g., packs generate-cache instead of packs generate_cache? This would be more typical, git uses dashes too
Yeah, I was thinking about shipping prebuilt binaries within ruby gems. Might be nice to avoid folks having to install any toolchains, and works well with rust since its binaries contain the entire required runtime (no other dependencies). I didn’t realize homebrew doesn’t work with linux.
Dashes vs. hyphens – not strongly opinionated. I was trying to copy packwerk and the ruby ecosystem of CLI tools (since it’s for now a ruby only tool), but there might be other stronger standards to use for CLI command naming.
Message originally sent by slack user U717FXJ8HWK
There’s Homebrew for Linux, however, it’s not as popular as far as I can tell
Message originally sent by slack user U717FXJ8HWK
Packwerk uses dashes too: packwerk update-todo
confirmed I’m getting the same results with packs and packwerk 
Message originally sent by slack user U70TIGAX94P
Packwerk actually already parses files for definitions, but then throws them away! It does that so it can collect “local definitions,” which are ignored as an early optimization (to save time during checking).
That’s not an optimization, it’s necessary so that the guesswork through constant_resolver works. It would otherwise guess they are defined elsewhere, in many cases. Constant_resolver only works for constants that are resolved through their path, as they would otherwise not have to follow zeitwerk conventions.
Also, it only does that for files that are scanned. That’s the important difference here. As I said, it was designed as a tool to scan single files without having to parse the whole codebase.