<p><code>fst</code> is the package I posted to practice community-related workflows, including writing documentation, using <em>travis-ci</em>, setting up vanity URL redirection. The <code>fst</code> package adds convenience routines for testing filesystem-related logic, helps to create, clone, cleanup, and compare directory trees.</p>
<p>It would be great to have some feedback about how approachable is the package - both from the user-facing information and from API perspective:</p>
<p><a href="https://github.com/didenko/fst/tree/master" rel="nofollow">https://github.com/didenko/fst/tree/master</a></p>
<p><strong>Added</strong> concerns after the question feedback at Stack Exchange:</p>
<p>Specific features used as user-facing conveniences are:</p>
<ul>
<li>Provided the license in a standard location</li>
<li>Most useful API functions highlighted in the front-page README</li>
<li>All Exported functions documented via GoDoc, made sure it correctly published to Go's <a href="https://godoc.org/go.didenko.com/fst" rel="nofollow">GoDoc</a> website</li>
<li>Integrated <em>Travis CI</em> continuous build</li>
<li>Followed semantic versioning guidelines</li>
</ul>
<p>Controversially:</p>
<ul>
<li>Marked the <code>dev</code> branch as default instead of <code>master</code></li>
<li>Used the <code>0.1.0</code> tag instead of beta designation, like <code>1.0.0-beta.1</code></li>
<li>Tagged minor patch as <code>0.1.1</code> after the original <code>0.1.0</code> release</li>
<li>Even though non-master default branch triggers a bug in the <a href="https://goreportcard.com/report/go.didenko.com/fst" rel="nofollow">Go Report Card</a>, still included the badge, albeit it reviews a previous version of the code.</li>
</ul>
<p>Should any of that be done differently, or is something missing?</p>
<hr/>**评论：**<br/><br/>sacrehubert: <pre><p>I like it. Godoc is great, but it's always nice to have an introductory demo that shows usage patterns in addition to function arguments. It's nice that you did that!</p>
<p>I'm writing a file synchronization client, so I'm tempted to give this a whirl. Incidentally, I'm looking for some mention of whether or not this library is production-ready. That would be a nice addition :)</p></pre>vlad_didenko: <pre><p>Good call about production-ready, thank you! I did use it in internal production for a while and the only reason I did not post <code>fst</code> as <code>v1.0.0</code> today is to do so after this feedback about metadata. I will do so a couple weeks after a last suggestion fix I get on this version.</p></pre>ChristophBerger: <pre><p>Nice! This might be a good fit to <a href="https://github.com/spf13/afero" rel="nofollow">Afero</a>, esp. with a memory-mapped FS.</p></pre>vlad_didenko: <pre><p>Interesting that you mention an @spf13 project. I totally forgot about it, but the first time I thought of techniques used in <code>fst</code> was when testing my changes in another Steve's project, <a href="https://github.com/spf13/viper/commit/9fca10189b1307bba68b2cd487dd93da0bfbda06#diff-db3e9f98aa59a770129eb45f83357512R132" rel="nofollow">Viper</a>. Nice reminder :)</p></pre>ChristophBerger: <pre><p>FWIW, my blog is powered by spf13‘s <a href="https://gohugo.io" rel="nofollow">Hugo</a>.</p></pre>epiris: <pre><p>Things I would do:</p>
<ul>
<li>Place test folders (mock_) should probably in a testdata dir.</li>
<li>Merge most of the project into 1-3 file / test pairs. I never have a file with a single function, if it has no good place to live it goes in pkgname.go.</li>
<li>The test coverage seems really light, but file system access is not something to be taken lightly. This may not apply to your project at all if you don’t delete files, creating is less dangerous.</li>
<li>I don’t want to be responsible for the security of people who rely on my packages, so I don’t host my repositories. This is a contentious topic so take it with a grain of salt, just something to think about.</li>
</ul>
<p>I’ve made similar helpers as I’ve needed in the past and I try minimize potential issues by setting a jailed root in a init that is a absolute path to cwd + testdata. Then you can easily send a path through a toJail func, so worst case scenario in a bad test you lose your testdata folder. Tmp folders / files are a potential exception if you returns closure for cleanup functions instead of accept a path.</p></pre>
