Ongoing maintenance / moduleIndex entry skipping

[mikeauclair]

Hi!

I'm working on a change for this tool that will allow for skipping uploads for moduleIndex entries (they are lightweight and depend on file mtime, which thrashes run-to-run for us, so they never get reused). I wanted to check in here real quick to see if there are plans to maintain this ongoing (in which case I'll open an upstream PR), or if I should just fork the repo to my company's org and work there in an ongoing fashion. No big deal either way, just want to know before I deal with rewriting module paths, etc.

Thanks!

[creachadair]

I'm working on a change for this tool that will allow for skipping uploads for moduleIndex entries (they are lightweight and depend on file mtime, which thrashes run-to-run for us, so they never get reused). I wanted to check in here real quick to see if there are plans to maintain this ongoing (in which case I'll open an upstream PR), or if I should just fork the repo to my company's org and work there in an ongoing fashion. No big deal either way, just want to know before I deal with rewriting module paths, etc.

I expect we'll continue to maintain the package as far as its existing functionality. As for additional features and other changes, I'd say it largely depends how invasive the proposal might be: Something we could add in as simple options on the existing APIs without too much violence seems fine. Larger structural changes may be better off living in a fork.

For your example here, I'm not sure what your desired API would look like: If it's simply a matter of adding some kind of hook to make a go/no-go decision before pushing to S3, that would probably be fine. Happy to discuss it further if you feel like adding more details.