Sorry for the delayed response - busy week!

I haven't had time to reproduce this yet, but it's possible we could be falling into a hole here related to code generation. dep is built around the assumption that the dependencies you pull in need no post-processing (codegen) of any kind - that everything that might be needed is committed. This isn't necessarily the best assumption, but it's held so far.

I think we also may have changed our error reporting a bit since you experienced this issue - could you re-grab the latest version of dep and re-attempt, and report the results? I'll also try to replicate when I find some time.

The output isn't much different save for the fact the the command completes in half the time now.

dep2.txt

As far as design, the go tool by design ignores files starting with underscore, so I expected the same behavior here, for the sake of consistency. Might be worth considering, since underscore files are technically not required for builds. Maybe a flag to include them if you feel otherwise, or the opposite flag to exclude them. Though the thought of the latter would make dep feel incorrect relative to the go cmd.

The leading underscores thing is interesting, and isn't something we've accounted for in the parser thus far. Adding something to skip them would be trivial, but it could have complicated effects - if there's any circumstance in which you actually DO need those deps (e.g., to build a supporting tool for codegen), and at a reliable version, then they do need to be included in analysis. Computing deps has less in common with compiling than it might seem at first - as described in #291, compiling operates on a concrete input set, but we have to operate across potential source combinations.

In particular, CLI flags to control such behaviors is something we're trying hard to avoid. Having a flag to control this behavior doesn't change a compiled binary - it changes your lock file. Which means everyone on your team (and all of their supporting tooling) would have to know to pass the same flags, otherwise your computed results start changing for no apparent reason. (We could, of course, allow these options to be written into the manifest, which is more possible...but at that point, it's a question of trying to avoid adding complexity by giving configuration choices that don't add much value)

ALL that said...I'm not actually sure that reading underscore-led files has anything to do with this. The specific error being reported is that there's a problem with an internal package imported by typewriter...but that shouldn't be possible, because typewriter has no subpackages. That seems like the spot where I'll need to dive in.

i believe this is wrapped up now