打造Snowpack到20,000 Stars的5個經(jīng)驗(yàn)之談
點(diǎn)擊上方 前端瓶子君，關(guān)注公眾號
回復(fù)算法，加入前端編程面試算法每日一題群
My name is Fred, and I created Snowpack. If you're not familiar, Snowpack is a web build tool that fundamentally unlocked the "unbundled web development" movement that Snowpack, Vite, SvelteKit and other modern dev tools leverage today.
我叫Fred，我創(chuàng)建了Snowpack。如果你還不熟悉，可以告訴你，Snowpack是一個web構(gòu)建工具，它從根本上開啟了Snowpack、Vite、SvelteKit和其他現(xiàn)代開發(fā)工具所利用的“非捆綁web開發(fā)”運(yùn)動。
In this post, I want to share 5 things that I learned growing Snowpack from the initial commit to almost 20,000 GitHub stars and over 1,000,000+ downloads.
在這篇文章中，我想和大家分享我從 Snowpack 中學(xué)到的5件事情，這些事情從最初提交到將近20000個 GitHub stars 和超過1000000次的下載中學(xué)到的。
This post is meant for anyone interested in Open Source software. The highlighted lessons are directed at anyone who is interested in starting their own open source project or contributing to an existing project.
這篇文章是寫給所有對開源軟件感興趣的人的。重點(diǎn)介紹是針對那些有興趣開始自己的開源項(xiàng)目或?yàn)楝F(xiàn)有項(xiàng)目做貢獻(xiàn)的人。
This will be a 2-part series: In this first post I focus on lessons learned creating Snowpack from scratch and finding our first set of users. In part two, I will focus what it's like to maintain a popular open source project, at scale.
這將是一個兩部分組成的系列。在第一篇文章中，我將重點(diǎn)介紹從零開始創(chuàng)建Snowpack和尋找第一批用戶的經(jīng)驗(yàn)教訓(xùn)。在第二部分中，我將重點(diǎn)介紹如何大規(guī)模維護(hù)一個受歡迎的開源項(xiàng)目。
Background
項(xiàng)目背景
A couple of years ago, I started an experimental JavaScript project. Codename: Pika. It had a cute, blue mouse mascot and a fun vibe that a bunch of smaller experimental projects could live under. Its unifying mission could be best summarized as, "ESM is this cool new technology, lets do more stuff with it."
幾年前，我開始了一個實(shí)驗(yàn)性的JavaScript項(xiàng)目。代號：Pika。它有一個可愛的、藍(lán)色的老鼠吉祥物和一堆小實(shí)驗(yàn)項(xiàng)目可以生活的有趣的氛圍。它的統(tǒng)一使命可以最好地概括為："ESM是一項(xiàng)很酷的新技術(shù)，讓我們用它做更多的事情。"
That first year of Pika may have been the most productive year of my life. I created @pika/pack (a publishing tool for npm package authors), Pika CI (a Github action that let you npm install or even import() any GitHub PR), a failed in-browser code editor, and a next-gen JavaScript CDN that went on become Skypack.
Pika的第一年可能是我一生中收獲最多的一年。我創(chuàng)建了@pika/pack（一個為npm包作者的發(fā)布工具），Pika CI（一個Github action，允許npm安裝甚至導(dǎo)入任何GitHub PR），一個失敗的瀏覽器內(nèi)代碼編輯器，以及一個繼續(xù)運(yùn)行的下一代的JavaScript CDN，后來成為Skypack。
The biggest standout of the bunch was @pika/web, which let you install any npm package to run directly in the browser without a bundler (ex: react -> /react.js). You probably know this project better under its newer name: Snowpack.
其中最突出的是@pika/web，它允許你安裝任何npm包，直接在瀏覽器中運(yùn)行，而無需bundler（例如：react -> /react.js）。你可能更了解這個項(xiàng)目的新名字：Snowpack。
Below are five lessons that I learned while growing Snowpack from its first commit to the official v1.0 release, and how we found our first set of users.
下面是我從Snowpack從第一次提交到正式發(fā)布V1.0版本的過程中學(xué)到的五條經(jīng)驗(yàn)，以及我們?nèi)绾握业降谝慌脩舻摹?/span>
Lesson 1: Start with a personal frustration
第一課：從個人挫折感開始
Snowpack began as a tool to convert any npm package to a single JavaScript file that you could run in the browser. Sounds boring, right? Wrong!
Snowpack最初是一個將任何npm包轉(zhuǎn)換為單一的JavaScript文件的工具，以便在瀏覽器中運(yùn)行。聽起來很無聊，對嗎？錯了!
This small, straightforward tool would unlock an entirely new mode of web development that is now referred to as "Unbundled Web Development". Unbundled development introduced features like instant reloads and near-instant startup time during development, using a process that wouldn't slow down as your project grows to 1,000 or even 10,000+ files. Compare this to more traditional bundled dev environments, where multi-second startup and reload times are still the norm today.
這個小巧簡單的工具將開啟一種全新的web開發(fā)模式，現(xiàn)在被稱為 "Unbundled式網(wǎng)絡(luò)開發(fā)"。Unbundled式開發(fā)引入了一些特性，比如在開發(fā)過程中即時重載和近乎即時的啟動時間，使用的流程不會隨著項(xiàng)目增長到1,000甚至10,000多個文件而變慢。相比之下，幾秒的啟動和重新加載時間今天仍然是常態(tài)。
The original idea for Snowpack came out of a simple, personal frustration that I had been having at work. I was working on the Polymer team at Google, where I had helped create some alterative build tools for the (now dead) HTML Imports spec. The tool itself was lovely, but it didn't work well with npm and very few people ever used it.
Snowpack的最初想法來自于我在工作中遇到的一個簡單的個人的挫折。我當(dāng)時在谷歌的Polymer團(tuán)隊(duì)工作，在那里我?guī)椭鷦?chuàng)建了一些替代性的 HTML Imports 規(guī)范構(gòu)建工具。這個工具本身很好，但它與npm不兼容，很少有人使用它。
I eventually left the Polymer team, but that problem still stuck in my head: Why had bundlers like webpack become the only way to use npm packages in the browser? Something has to solve the problem of getting npm packages to run in the browser, but did it have to involve bundling your entire website? Snowpack was my attempt to find out whether another path was possible.
我最終離開了Polymer團(tuán)隊(duì)，但是那個問題仍然困擾著我：為什么像webpack這樣的打包器成了在瀏覽器中使用npm包的唯一方式？必須要有辦法解決讓npm包在瀏覽器中運(yùn)行的問題，但是否一定要把你的整個網(wǎng)站捆綁起來？Snowpack是我試圖找出另一條路是否可行的嘗試。
Lesson for open source maintainers: Build for yourself, first. If you're frustrated by something, chances are other developers are too. Question everything.
給開源維護(hù)者的教訓(xùn)：首先為自己構(gòu)建。如果你對某件事情感到沮喪，那么其他開發(fā)者也有可能會這樣。質(zhì)疑一切。
Lesson 2: move fast, stay small
第二課：快速行動，保持低調(diào)
When you're working on a new project, you rarely know what code will be important long-term and what code is about to be deleted. I've thrown away enough code in my career to have learned that there's sometimes value in fast, messy coding. When you're starting a new project, it's okay to be a bit messy.
當(dāng)你在一個新項(xiàng)目上工作時，你很少知道哪些代碼將是重要的，哪些代碼即將被刪除。在我的職業(yè)生涯中，我已經(jīng)丟棄了足夠多的代碼，從而了解到快速而混亂的編碼有時是有價值的。當(dāng)你開始一個新的項(xiàng)目時，有點(diǎn)亂是可以的。
Internally, almost all of Snowpack's complexity was handled by Rollup. Snowpack was really just a wrapper around Rollup that would bundle only your npm packages instead of your entire website. Realizing that Snowpack could leverage Rollup internally saved me weeks (or maybe even months) of development time.
在內(nèi)部，幾乎所有Snowpack的復(fù)雜性都由Rollup處理。Snowpack實(shí)際上只是一個圍繞Rollup的包裝器，它只打包你的npm包，而不是你的整個網(wǎng)站。意識到Snowpack可以在內(nèi)部利用Rollup，為我節(jié)省了數(shù)周（甚至數(shù)個月）的開發(fā)時間。
To be honest, Snowpack was just a single index.js file for the majority of its life.
說實(shí)話，Snowpack的大部分時間只是一個index.js文件。
To keep the project on track, I focused on a single feature: "give me a package name, and I'll convert it to ESM." This would be too low-level for most web developers. In fairness, Snowpack really didn't take off with a large audience until we added a built-in dev server and build command in v2.0. But even without the dev server, Snowpack's small v1.0 focus was enough for a certain kind of low-tooling/no-tooling web developer.
為了保持項(xiàng)目的進(jìn)度，我把注意力集中在一個單一的功能上。"給我一個包名，我就把它轉(zhuǎn)換為ESM"。這對大多數(shù)網(wǎng)絡(luò)開發(fā)者來說太低級了。公平地說，直到我們在2.0版中添加了內(nèi)置的開發(fā)服務(wù)器和構(gòu)建命令，Snowpack才真正獲得了大量用戶。但即使沒有開發(fā)服務(wù)器，Snowpack對1.0版本的關(guān)注也足以滿足某種低工具/無工具的web開發(fā)人員。
My overeall recommendation is to test your idea and get together a working demo as quickly as possible. In practice, this means four things:
我的建議是盡快測試你的想法，并制作一個可運(yùn)行的demo。實(shí)際上，這意味著四件事：
Use existing tools! Fork a similar open source project or use an existing tool internally if it can save you time.
使用現(xiàn)有的工具! 如果可以節(jié)省你的時間，那么就Fork一個類似的開源項(xiàng)目，或者在內(nèi)部使用現(xiàn)有的工具。
Write messy code! At the earliest stage, you probably don't know exactly know what you're building. Premature refactoring can sometimes be worse than never refactoring at all, so keep your code flexible for as long as possible.
編寫混亂的代碼! 在最初的階段，你可能并不確切知道你在構(gòu)建什么。過早的重構(gòu)有時會比根本沒有重構(gòu)更糟糕，所以盡可能的保持你的代碼的靈活性。
Keep scope small! Don't build half-baked, half-working features. Instead, focus on doing one thing very well.
保持小范圍! 不要構(gòu)建半成品功能。相反，要專注于把一件事做得非常好。
Skip tests! Confirm that you're building something useful before spending your free time writing tests for it. Nothing is worse than writing tests for something that you end up never using.
跳過測試! 在空閑時間編寫測試之前，確認(rèn)你正在構(gòu)建一些有用的東西。沒有什么比為一些你最終不會使用的東西寫測試更糟糕的了。
I know that some of this could be considered a hot/controversial take. "No testing??? Blasphemy!" All I can say is that this strategy has worked well for me over several popular projects and countless unpopular projects that went nowhere.
我知道這其中有一些可能被認(rèn)為是熱門/有爭議的觀點(diǎn)。"沒有測試？褻瀆！" 我所能說的是，這個策略在我的幾個受歡迎的項(xiàng)目和無數(shù)不受歡迎的項(xiàng)目中都很有效。
The obvious downside to this "move fast" advise is that it is not sustainable long-term. Moving fast means taking on tech debt, which you will absolutely need to repay at some point if your project becomes successful. As soon as you have some users who like what you're doing, you should begin to re-prioritize stability, refactoring and testing. More on this in the next post.
這種 "快速行動 "的建議的明顯缺點(diǎn)是，從長期來看，它是不可持續(xù)。快速行動意味著承擔(dān)技術(shù)債務(wù)，如果你的項(xiàng)目成功了，你絕對需要在某個時候償還這些債務(wù)。一旦有一些用戶喜歡你所做的事情，您就應(yīng)該開始重新優(yōu)先考慮穩(wěn)定性、重構(gòu)和測試。在下一篇文章中會有更多這方面的內(nèi)容。
Paying down tech debt can be a slog. But, silver lining: If your project never takes off, then congratulations! You didn't waste any time testing something that no one wanted :)
償還技術(shù)債務(wù)可能是一件苦差事。但是幸運(yùn)的是。如果你的項(xiàng)目沒有成功，那么恭喜你！你沒有浪費(fèi)任何時間去測試那些沒有人想要的東西 :)
Lesson for open source maintainers: Write messy code, keep scope small, and skip any unnecessary work until you know that you're building something useful.
對開源維護(hù)者的教訓(xùn)：寫亂七八糟的代碼，保持較小的范圍，跳過任何不必要的工作，直到你知道你正在構(gòu)建有用的東西。
Lesson 3: Fix fast
第三課：快速修復(fù)
You just received your first bug report. Oh no, someone tried your project out and it broke! But what matters is that they cared enough to tell you about it.
你剛剛收到你的第一個錯誤報告。哦，不，有人試用了你的項(xiàng)目，結(jié)果它壞了！但重要的是，他們關(guān)心并告訴你這個問題。
One of the best things that you can do in a new open source project is fix bug reports right as they come in. Prioritizing fixes over everything else becomes much harder as a project grows, so enjoy the freedom to move quickly while you still can.
在一個新的開源項(xiàng)目中，你可以做的最好的事情之一就是在收到錯誤報告時立即修復(fù)。隨著項(xiàng)目的發(fā)展，將修復(fù)優(yōu)先于其他任何事情會變得更加困難，所以在你還可以的時候，請享受快速行動的自由。
Sebastian McKenzie (creator of Babel, Yarn, and now Rome) summarizes this theory well:
Sebastian McKenzie（Babel、Yarn和現(xiàn)在的Rome的創(chuàng)建者）很好地總結(jié)了這個理論：
One of the reasons Babel was successful is how quickly I was able to quickly fix bugs and release new versions. I would regularly have releases out within minutes of a bug report. This was critical during the early days when adoption was low. Being able to unblock users quickly would often make them more excited to use Babel even though they ran into a bug. -- Sebastian McKenzie, Rome
Babel成功的原因之一是我能夠快速地修復(fù)bug并發(fā)布新版本。我經(jīng)常在接到錯誤報告后幾分鐘內(nèi)就發(fā)布了新版本。在采用率低的早期，這至關(guān)重要的。如果能夠快速解鎖用戶，他們就會更樂意使用Babel，即使他們遇到了錯誤。-- Sebastian McKenzie，羅馬
Lesson for open source maintainers: Your first users are essential. Prioritize fixing their issues over everything else.
對開源維護(hù)者的教訓(xùn):你的第一批用戶是至關(guān)重要的。優(yōu)先解決他們的問題。
Lesson 4: Practice good storytelling
第四課：練習(xí)講好故事
Something about marketing always seems to make developers squeamish. Unfortunately, if you want people to use your project you eventually need to tell them about it. Even organic, viral word-of-mouth sensations tend to have a cheerleader acting behind-the-scenes.
關(guān)于市場營銷的東西似乎總是讓開發(fā)者感到膽怯。不幸的是，如果你想讓人們使用你的項(xiàng)目，你最終需要告訴他們它。即使是有機(jī)的、病毒式的口碑傳播，也往往有一個拉拉隊(duì)在幕后行動。
To start, just share your project with a friend or colleague and ask them for their thoughts. It's okay if you don't hit the front page of Hacker News on day one, all you're looking for is early feedback and maybe your first users.
首先，與朋友或同事分享你的項(xiàng)目，并征求他們的想法。如果你沒有在第一天就登上Hacker News的頭版也沒關(guān)系，你所尋找的只是早期的反饋，也許是你的第一批用戶。
When you're ready to share your project with a larger audience, you have a few options for how to do it. One popular choice is to tell your story in small, visual pieces over time. This is how Sebastian built excitement for Rome for almost 2 years before its launch. Mark Dalgleish has also done a great job of promoting vanilla-extract on Twitter this way.
當(dāng)你準(zhǔn)備與更多的人分享你的項(xiàng)目時，你有幾個選擇來做這件事。一個流行的選擇是，隨著時間的推移，用小的、可視覺化的作品來講述你的故事。這就是塞巴斯蒂安如何在《羅馬》推出前的2年時間里為它制造興奮。馬克-達(dá)格利什（Mark Dalgleish）也用這種方式在推特上推廣了香草提取物。
You can also get creative, and do something unique. Ben Holmes has been having a ton of fun recording announcement videos in front of a whiteboard for his new project, Slinkity.
你也可以變得有創(chuàng)意，做一些獨(dú)特的事情。本·霍姆斯(Ben Holmes)為他的新項(xiàng)目Slinkity在白板前錄制了大量有趣的宣傳視頻。
With Snowpack, I decided to tell our story in one big blog post. This took some serious time to write, but gave us the space to really explain the "why" of the project. I figured that we had to make an emotion connection to our bigger goal to change the web. Even though this was just a single post, it made a big splash when it was released and then got re-shared and referenced over the next year.
對于Snowpack，我決定用一篇大的博客文章講述我們的故事。這需要花一些時間來編寫，但這也給了我們足夠的空間來真正解釋這個項(xiàng)目的“原因”。我認(rèn)為我們必須將情感與改變網(wǎng)絡(luò)的更大目標(biāo)聯(lián)系起來。盡管這只是一篇文章，但它在發(fā)布時引起了很大的轟動，然后在接下來的一年里被重新分享和引用。
Lesson for open source maintainers: Promote your work. Find a style of storytelling that fits you and your project.
開源維護(hù)者的教訓(xùn)：推廣你的工作。找一種適合你和你的項(xiàng)目的講故事的方式。
Lesson 5: Ignore your haters, listen to your users
第五課：忽略你的討厭者，傾聽你的用戶
If your work ever gets posted to Hacker News, expect some haters.
如果你的作品被發(fā)布到Hacker News上，恐怕會有人討厭你。
If you're lucky, you can tell the difference between ignorant criticism and constructive criticism. Ignore the ignorant stuff (aka haters) but listen to the constructive feedback if you can. If someone shows that they took the time to at least attempt to understand your project in good faith, their feedback will usually have some value if you can spot.
如果你幸運(yùn)的話，你可以分辨出無知的批評和建設(shè)性的批評。忽略那些無知的東西（也就是討厭的人），但如果可以的話，聽聽建設(shè)性的反饋。如果有人愿意花時間去理解你的項(xiàng)目，他們的反饋通常是有價值的。
A common constructive criticism is when someone clearly tried understand your work, but still misunderstood some key part of it. It's easy to call that person dumb and move on, but remember that clear communication is your responsibility. When someone misunderstands your work, it usually means that you could improve your README or documentation or general storytelling in some way.
一種常見的建設(shè)性批評是，有人清楚地試圖理解你的工作，但仍然誤解了其中的一些關(guān)鍵部分。罵那個人是很容易的，但請記住，清晰的溝通是你的責(zé)任。當(dāng)有人誤解你的工作時，這通常意味著你可以在某些方面改進(jìn)你的README或文檔或一般的敘述方式。
Lesson for open source maintainers: Haters gonna hate, ignore them. Learn how to spot the good-faith, constructive criticism.
開源維護(hù)者的教訓(xùn)：討厭的人就是討厭，不要理會他們。學(xué)習(xí)如何識別善意的、建設(shè)性的批評。
Main Takeaway: Support your early users
主要啟示：支持你的早期用戶
If you're starting a new open source project, the best thing that you can do is make sure that your first 10 users are happy. All of the lessons above are really just about finding and supporting these first users in some way. If you do right by them, then you've already built something meaningful.
如果你正在啟動一個新的開源項(xiàng)目，你能做的最好的事情就是確保你的前10個用戶是滿意的。以上所有的教訓(xùn)實(shí)際上是關(guān)于如何找到并支持第一批用戶。如果你對他們做得對，那么你就已經(jīng)建立了一些有意義的東西。
And if this all sounds like too much work, remember that open source software has no rules. It's supposed to be fun. Building for yourself or a smaller audience is totally fine, in which case you can go ahead and ignore most of this advice.
如果這一切聽起來像太多的工作，請記住，開放源碼軟件是沒有規(guī)則的。它應(yīng)該是有趣的。為自己或更少的用戶構(gòu)建是完全可以的，在這種情況下，你可以忽略大部分建議。
Snowpack項(xiàng)目地址：https://github.com/snowpackjs/snowpack
關(guān)于本文
譯者：@飄飄
作者：@Fred K. Schott
原文：https://dev.to/fredkschott/5-things-i-learned-while-building-snowpack-to-20-000-stars-b9d