Repo style questions

[jamen]

I have some questions for the style of the repos we could establish further here to clean up any inconsistencies

1. Should we push yarn.lock or should it be inside .gitignore?
   • Helpful when someone clones the repo and uses the lockfile to download the deps
   • More consistent installs between collaborators and Travis CI, and other benefits of a lockfile
   • Not helpful when published, so it should be npm ignored (see below)
2. Should we use .npmignore or "files"?
   • I personally prefer files option and less dotfiles in general
   • npmignore has a "more safe" mechanism by being opt-out, so you are more unlikely to accidentally publish with missing files (unless there is a tool out there that checks for you?)
3. How should files be cased? README vs readme, LICENSE vs license, etc.
4. Should we have one readme style across the board? Possibly with a template scaffolding and/or tool (e.g. yo, generate, or bp for simple stuff)
5. Should we more eagerly link back to some origin repository or page (like audiojs.github.io or github.com/audiojs/audio, etc.) near the title area, to tie everything back together nicely. Another method people seem to take is monorepos, but that might deviate too far from the style we have established and I'm not sure about them myself yet.
6. How should we organize different clusters of packages with npm keywords, audiojs/docs, and so on. For example: pull-audio-* packages can be categorized by a pull-audio keyword, and cli packages by audio-cli, etc. but you also have groups going the other direction like audio-gain and it having pull, stream, and cli packages

[dy]

1. :+1:, although I don't use yarn.
2. There's been lot of hype about broken "files" option in npm, so def .npmignore
3. :+1: for lowercase with extension, ie readme.md, license.md
4. I would go for minimally required ecosystem badges like build, stability and greenkeeper, and basic sections usage and api, the later is optional if module is self-explanatory. The rest is up to author, optionally table of content, credits, related, other badges, contributors, donate bitcoins etc.
5. :+1: for that, mb we can do elegant @audiojs badge, like here. That also enhances ux/seo.
6. I'd go for removing bad tags and leaving only ecosystem ones: pull-stream, audiojs, stream, cli etc. Because that drops our reputation when someone types dsp or fft in npm search and sees unrelated audio-* packages like audio-shader or audio-through.

[jamen]

With npm 5 out, we should use package-lock.json instead of yarn.lock

[jamen]

New opinion about lockfiles: Maybe we should keep them ignored?

• It can be distracting inside git diff
• Not that useful for small libraries
• Makes the developers depend on lockfile while the users are depending on package.json fields.

[dy]

Agreed 100% :) Tbh npm@5 was a pain for me with all the installing trickery, switched back to v4