假设你想要开源一个小东西...

假设你写了一个超级好用的 JavaScript 小片段。 太棒了！干得好，你。 当然，全世界都能从这个中获益。 至少有一小部分人。 不用把它锁起来。 你在职业生涯中从开源中获益良多。 这是一个回馈的好机会！

让我们来做这个。

你需要把它扔到一个 GitHub 仓库中。 对于开源来说，这就像必不可少的东西。 这是人们可以找到它、链接到它、查看代码以及其他所有操作的地方。 如果你需要，它也是一个你可以推送更改的地方。

你需要选择一个许可证。 如果这个的重点是“回馈”，你真的需要这样做，否则，它本质上就像你拥有它的独家版权一样。 有点违反直觉，但选择一个许可证会打开使用权限，而不是收紧它。

你需要在里面放一个 README。 虽然你认为你的代码已经非常自文档化了，但它并不是。 你需要一些简单的语言在里面解释你的东西是什么以及它的作用。 使用示例至关重要。

你可能还想在那里放一些演示。 也许是一个完整的 `/demos/` 目录，这样证明就可以用事实说话了。

在你制作了一些演示之后，你可能也会在里面放一些测试。 它们是相辅相成的。 测试可以让可能使用你东西的人安心，让他们相信它将可以正常工作，以及作为作者，你关心确保它能够正常工作。 如果你计划保持你的东西更新，测试将确保你在进行更改时不会破坏东西。

说到人们使用你的东西... 他们究竟要怎么使用它？ 你可能不能只是在 `the-thing.js` 中留一个原始的 `function theThing ()`！ 这不是 1800 年代，他们会告诉你的。 你甚至没有用 IIFE 包裹它？！ 你至少应该把它做成单例。

人们会想要 `const theThing = require("the-thing.js");` 它。 这是 CommonJS 格式，这似乎是合理的。 但这更适用于 Node.js 而不是浏览器，所以使用 `define()` 并返回一个函数（也称为 AMD）似乎也是合理的。 幸运的是，有UMD，它就像这两个格式同时存在一样。

等等等等。 ES6 现在已经正式到来，它有自己的模块格式。 人们肯定会想要 `import { theThing } from './the-thing.js';`，这意味着你需要 `export function theThing() { }`。

那么你应该在这里做什么？ heck 我不知道。 我相信评论中会有人说些什么。

无论你决定做什么，你可能都会将这个“模块”问题与你创作的代码分离。 也许一个构建流程可以帮助你将所有这些组合在一起。 也许你可以提供所有不同的模块格式，这样每个人都会满意。 你用什么来进行构建流程？ Grunt？ Gulp？ 太老了？ 现在很酷的是一个 npm 脚本，它只是将一些终端命令放到 `package.json` 文件中。

在进行构建处理时，你可能也会让它运行你的测试。 你也可能要创建一个缩小的版本。 每个库都有一个 `the-thing.min.js`，对吧？ 你可能也会把所有这些自动生成的代码放到 `/dist/` 文件夹中。 也许你甚至会非常酷，不会把它检入到仓库中。 如果你想要这个东西，你只需要获取仓库并自己构建它！

尽管如此，你还是希望人们使用这个东西。 有公开仓库还不够，它还需要发布到 npm上，这是一个完全不同的网站和世界。 希望你早些时候做了些命名研究，因为你需要给你的包命名，并且这个名字必须是唯一的。 这里还有很多其他需要注意的东西，比如确保仓库很干净，并且你已经忽略了你不想让每个人都下载的那些东西。

等等，Yarn 是什么？ 它不是新版的 npm 还是什么？ 你可能还想在那里发布。 一些人仍然坚持使用Bower，所以你可能还想让你的东西在那里也能用。

好了！ 完成了！ 休息一会儿，准备好应对问题板上不断涌入的需求吧！

只是开玩笑，一切都会好起来的。