Prettier का $20k bounty, Biome ने किया claim

 (prettier.io)
3 पॉइंट द्वारा GN⁺ 2023-11-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • JavaScript code formatter Prettier ने formatting logic लगभग स्थिर स्तर पर पहुँचने के बाद, Rust-आधारित compatible implementation के जरिए performance competition को बढ़ावा देने की कोशिश की
  • 9 नवंबर को Prettier ने test suite 95% pass करने की शर्त पर $10,000 का bounty घोषित किया, और Vercel CEO Guillermo Rauch तथा napi.rs के अतिरिक्त योगदान से कुल राशि $22,500 हो गई
  • Biome ने लगभग 3 हफ्तों में कई लोगों की मदद से compatibility बढ़ाकर bounty हासिल किया, और इस प्रक्रिया में Prettier के साथ वास्तविक compatibility का दायरा तेज़ी से बढ़ा
  • tests मिलाने की प्रक्रिया में Prettier के bugs और questionable decisions भी सामने आए, जिससे Prettier पक्ष को भी सुधार के ठोस आधार मिले
  • Prettier अब तक donations के सहारे 2 maintainers को हर महीने $1,500 देता रहा है, लेकिन मौजूदा बजट में केवल 8 महीने की runway बची है, इसलिए अतिरिक्त donations की ज़रूरत है

Biome ने Prettier का bounty हासिल किया

  • Prettier एक JavaScript code formatter है, जिसे लोगों के code लिखने के बेहद विविध तरीकों को सावधानी से संभालने की वजह से व्यापक रूप से अपनाया गया
  • formatting logic पहले से ही काफ़ी मजबूत स्थिति में है, और ternaries पर काम जुड़ जाने के बाद इसे संतोषजनक स्तर पर माना जा रहा है
  • अगली चुनौती performance improvement है
    • Prettier मूल रूप से कभी बहुत तेज़ tool नहीं था, लेकिन ज़्यादातर use cases के लिए पर्याप्त तेज़ था
    • मौजूदा स्थिति पर ठहर न जाए, इसलिए friendly competition के ज़रिए सुधार को प्रेरित किया गया

  • bounty की शर्तें और भागीदारी

    • 9 नवंबर को, Rust में लिखा गया कोई project अगर Prettier test suite का 95% pass कर ले, तो उसे मिलने वाले $10k bounty की घोषणा की गई
    • Vercel CEO Guillermo Rauch ने उतनी ही राशि और जोड़ दी, जिससे कुल रकम $20,000 हो गई
    • napi.rs ने $2,500 और जोड़े
    • Algora ने bounty के लिए landing page बनाया

  • Biome की उपलब्धि

    • Biome project ने bounty हासिल किया
    • लगभग 3 हफ्तों तक करीब 12 लोग जुटकर compatibility सुधारते रहे
    • अधिक विवरण Biome की full report में है
    • tests मिलाने की प्रक्रिया में Prettier के कई bugs and questionable decisions भी मिले, जिन्हें Prettier अब सुधार सकता है

performance competition से बना दबाव

  • Prettier टीम ने दूसरे project पर पैसा लगाने का कारण performance competition पैदा करना था
    • Prettier, JavaScript code formatter क्षेत्र में प्रमुख स्थिति में था
    • competition की कमी के कारण performance सुधारने और कई edge cases ठीक करने की प्रेरणा कम थी
  • अब Biome के पास Prettier-compatible लेकिन कहीं तेज़ implementation है, और users चाहें तो switch कर सकते हैं
  • Fabio Spampinato ने इस challenge के बाद Prettier CLI की सही तरह profiling की और कई बेहद चरम inefficiencies खोजीं
    • इन समस्याओं को साल के अंत तक ठीक करने की योजना है

Prettier के donations और maintenance budget

  • Prettier का bounty और इसका लगातार संचालन कई व्यक्तियों और कंपनियों के बड़े donations की बदौलत संभव हुआ

  • प्रमुख कंपनी donations

    • Indeed: $20,000
    • Frontend Masters: $10,850
    • Sentry: $10,529
    • Salesforce: $10,025
    • Airbnb: $8,426
    • Cybozu: $6,086

  • प्रमुख व्यक्तिगत donations

    • Shintaro Kaneko: $1,635
    • Suhail Doshi: $1,000
    • icchiman: $500
    • Mariusz Nowak: $270
    • Benoît Burgener: $270
    • Jeremy Combs: $270
    • f_subal: $230
    • इन donations की बदौलत Prettier पिछले 2 वर्षों से दो लोगों को हर महीने $1,500 का भुगतान करते हुए releases जारी करता रहा है
    • Fisker Cheung और Sosuke Suzuki यह भूमिका निभा रहे हैं
    • मौजूदा budget में केवल 8 महीने की runway बची है, इसलिए अतिरिक्त donations की ज़रूरत है
    • यदि आपने Prettier का उपयोग किया है और उससे मदद मिली है, तो आप https://opencollective.com/prettier पर donation दे सकते हैं
    • Open Collective project संचालन में बड़ी मदद करता है
    • maintainer व्यक्तिगत जानकारी दिए बिना sign up कर सकते हैं
    • यह बैंक की तरह काम करता है और दुनिया भर में पैसे भेजने और लेने की सुविधा देता है
    • यह tax documents को उचित ढंग से संभालता है
    • Prettier ने कुल $110,000 जुटाए हैं, जिनमें से $75,000 पुनर्वितरित किए जा चुके हैं
    • यह bounty एक बार का था, लेकिन लक्ष्य code formatting ecosystem में नई ऊर्जा भरना और बेहतर developer experience बनाना है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-11-28
Hacker News की रायें

  • यह जिज्ञासा तो थी कि Prettier टीम किसी दूसरे project को funding क्यों दे रही है, लेकिन जवाब पूरी तरह संतोषजनक नहीं लगा
    Prettier में सुधार के लिए bounty रखी जा सकती थी; Prettier को बेहतर बनाने की motivation पैदा करने के लिए एक competing project क्यों बनाना है, यह स्पष्ट नहीं है
    यह भी सोचने वाली बात है कि क्या अंतिम लक्ष्य Prettier को बंद करके Rust-आधारित tool पर shift करना है; और यह पहले से ही उलझे ecosystem को अनावश्यक रूप से और fragment करता दिखता है

    • Prettier सुधार bounty के बजाय यह अलग project क्यों बना, इसके तीन कारण दिखते हैं
      पहला, Rust में formatter लिखना Prettier codebase में सुधार करने से अलग प्रकृति का काम है। Prettier Rust में नहीं लिखा गया है, और Rust formatter implementation के लिए एक मजबूत विकल्प साबित हो चुका है, इसलिए लक्ष्य खुद Rust formatter लिखने के ज्यादा करीब है
      दूसरा, $20k में Prettier के ownership वाले Rust formatter को लिखने के लिए कहना आकर्षक नहीं है। किसी अच्छे developer के लिए यह लगभग 100 घंटे का काम भर है, जो project पूरा करने के लिए कम है; लेकिन अगर reward ऐसे project के रूप में मिले जिसका owner वही हो, तो यह कहीं ज्यादा आकर्षक हो जाता है
      तीसरा, अगर Prettier winning project का owner बनता है, तो maintenance की जिम्मेदारी भी Prettier team पर आ जाएगी। मूल बनाने वाली team के पास उसे लगातार maintain करने की incentive घटेगी, और competition भी खत्म हो जाएगा, जिससे ecosystem कम सक्रिय होगा
    • open source maintainer के नजरिए से, सब लोग मेरे किसी खास implementation का इस्तेमाल करें, इससे ज्यादा रुचि problem solve होने में होती है
      मेरे code का कोई इस्तेमाल करे तो मुझे सीधा फायदा भी नहीं होता; मैंने accessible solution बनाने के लिए काम किया था। अगर JS code formatting को लेकर passion है, तो कोई उस problem को और तेज तरीके से solve कर दे, यह देखकर भी काफी खुशी होगी
    • “हम मौजूदा dominant player हैं और JavaScript developers के पास इस्तेमाल लायक विकल्प नहीं है” और “Rust side ने कर दिखाया और एक काफी viable विकल्प सामने आ गया” — इन दोनों में बड़ा फर्क है
      यह local optimum से बाहर निकलने की समस्या जैसा लगता है। सबसे बड़े performance bottleneck को देखकर कहा जा सकता है कि इसे बेहतर किया जा सकता है, लेकिन objectively बेहतर comparison target न हो तो confident होना मुश्किल है
      imitation सबसे ईमानदार तारीफ है, और कठिन problem को दूसरी language में भी solve किया जा सकता है, यह तथ्य अपने आप में competition की प्रक्रिया में value बनाता है
      असली विकल्प न हो तो पूर्ण competition भी नहीं होता। अगर Rust implementation test suite का 5% से भी कम हिस्सा हटाकर भी तेज है, तो standard implementation से तुलना करने पर यह इस problem की theoretical limits के बारे में बहुत कुछ बताता है
      मैं इस क्षेत्र को बहुत गहराई से नहीं जानता, लेकिन मेरा मानना है कि किसी दूसरी language में similar implementation होने से मिलने वाली intangible value हमेशा होती है
    • अलग-अलग नजरिए और इरादों वाले लोग implement करें तो सुधार की नई दिशाएं सामने आ सकती हैं
      https://biomejs.dev/formatter/#differences-with-prettier
      Biome ने Prettier जैसे decisions follow नहीं किए और कई अलग हुए pain points खोजे, और सिर्फ यही parallel development की value साबित करने के लिए काफी है
    • अलग constraints और baggage वाला approach ऐसे improvement areas खोज सकता है जो original project में दिखते ही नहीं
      शायद इसलिए कि वह तथाकथित Prettier वाली सोच में फंसा नहीं है

  • कई लोग कारण बताते हुए भी इस हिस्से को साथ में नहीं देख रहे लगते: “सभी tests match करते हुए Biome project ने Prettier के कई bugs और questionable decisions खोजे, और उन्हें improve करना संभव हुआ”
    मुझे इसका मतलब यह लगता है कि दूसरे implementation के जरिए अपने implementation का sanity check करना संभव हो गया

  • यह खबर सच में exciting है
    Biome team ने Prettier के साथ 95% compatibility जिस speed से हासिल की, वह हैरान करने वाली थी https://github.com/biomejs/biome/issues/720
    Rust की वजह से JavaScript formatting की speed काफी बढ़ाई जा सकती है, और यह Python formatter ruff वाले trend को follow करता है
    article में नहीं है, लेकिन Wasmer ने भी Biome को WASIX में compile करने के लिए $2,500 bounty रखी थी, और उस team को इसके लिए काम करते देखना भी अच्छा लगा
    उम्मीद है कि जल्द ही Biome Wasmer पर चलेगा: https://wasmer.io/, https://wasix.org/, https://console.algora.io/challenges/prettier

    • WASIX पहली बार देखा; पढ़ने पर यह JVM के पुनर्जन्म जैसा लगता है
      जानना चाहूंगा कि क्या मेरी समझ सही है। अगर यह system तक access कर सकता है और असली sandbox नहीं है, तो WASIX में code चलाने का फायदा क्या है, समझ नहीं आता
    • जिज्ञासा है कि क्या किसी को पता है कि इसे WASIX में compile करने लायक बनाने की वजह क्या है

  • स्पीड में सुधार का हमेशा स्वागत है, लेकिन अच्छा होता अगर Prettier थोड़ा कम हठधर्मी होता
    खासकर लाइन की लंबाई के मामले में यह मेरी formatting को यूँ ही नहीं छोड़ता। Prettier से format किया गया code, बिना format किए code से काफी कम readable होता है, और यह समस्या rustfmt जैसे दूसरे formatter में नहीं आती

    • जानना चाहूँगा कि क्या कोई उदाहरण है जहाँ Prettier वाला code काफी कम readable हो
      मुझे ऐसी समस्या ज़्यादा नहीं आई और मैं Prettier से काफी संतुष्ट रहा हूँ
    • क्या आपने print width option आज़माया है: https://prettier.io/docs/en/options.html#print-width
    • Prettier की असली समस्या यह है कि यह लगभग de facto standard बन चुका है
      व्यक्तिगत रूप से मुझे Prettier बिल्कुल पसंद नहीं, लेकिन Svelte पसंद है, और जहाँ तक मुझे पता है Svelte का official formatter Prettier का उपयोग करता है। इसलिए Svelte के लिए Prettier इस्तेमाल करता हूँ, और कुछ अन्य चीज़ों के लिए भी यही है
      अगर स्थिति ऐसी हो कि user tool चुन रहा है, तो “बहुत हठधर्मी, और अगर configuration चाहिए तो कहीं और जाइए” वाला सिद्धांत बढ़िया हो सकता है। लेकिन जब यह किसी खास user base के लिए de facto इकलौता विकल्प बन जाए, तो इसे थोड़ा अधिक configurable होना चाहिए
    • लाइन की लंबाई के मामले में Prettier के और भी सूक्ष्म side effects हैं, इसलिए मैं हठधर्मी formatter से बचता हूँ
      Prettier अनचाहे तरीके से diff बदल देता है
      destructuring assignment में अगर आप एक member हटाएँ और वह line length limit से नीचे आ जाए, तो diff 0/-1 के बजाय +1/-5 हो सकता है। reviewer के लिए 5 lines हटने और 1 line जुड़ने के बीच ठीक-ठीक क्या निकला, यह तुरंत देखना मुश्किल होता है
      अगर Git के interactive rebase से किसी पुराने commit की typo ठीक करने की कोशिश करें, तो Prettier पूरे code block को फिर से format कर सकता है, जिससे अगले commits apply न भी हों
      pre-commit hook से Prettier चलवाने के बाद file के सिर्फ कुछ changes stage करके देखिए, फिर एक और मज़ेदार समस्या आती है। मैं तो इससे दूर ही रहूँगा
    • सहमत हूँ। बल्कि मैं तो यहाँ तक कहना चाहूँगा कि Prettier होता ही नहीं तो बेहतर होता

  • अभी भी इस बात से चिढ़ है कि कई eslint plugins ने अच्छे-भले linters हटाकर उन्हें Prettier से बदल दिया
    Prettier बहुत दबंग/थोपने वाला है, उसके बारे में reasoning करना मुश्किल है, और यह एक और tool है जिसे मैंने कभी चाहा ही नहीं

    • deprecated style rules को नए project में port कर दिया गया है: https://eslint.style/guide/why
    • ऐसे tool का मकसद ही style debates खत्म करना होता है
    • समझ नहीं आता कि किस स्थिति में Prettier के बारे में “reason” करना पड़ता है
      कभी-कभी merge conflict की समस्या आती है, बस वही याद आता है

  • Rust में port करने का trend तो है, लेकिन Prettier हर save पर चलता है, इसलिए speed improvement काफी बड़ा होगा
    जल्द ही Biome आज़माने वाला हूँ, और Biome project को बधाई

    • single file पर Prettier चलते समय मैंने कभी delay महसूस नहीं किया
      performance तब महत्वपूर्ण होती है जब पूरे repository पर formatting चलानी हो
      interactive use में एक लंबे समय तक चलने वाला और warmed-up process इस्तेमाल होना चाहिए, तब Node startup time मायने नहीं रखता। आदर्श रूप से type checking, linting, highlighting और formatting एक ही language service के भीतर हर key press पर incremental parsing करें और shared AST update करें
    • यह काम Python community में ruff को लेकर उत्साह की याद दिलाता है
      व्यापक असर डालने वाले efficiency और speed improvements की उम्मीद है
    • सुझाव है कि lint-staged tool इस्तेमाल करें ताकि Prettier हर save पर पूरे project पर नहीं, सिर्फ बदली हुई files पर चले
      बड़े projects में फर्क बहुत बड़ा होता है

  • “अब हम अगले महत्वपूर्ण पहलू, performance, पर ध्यान दे सकते हैं। Prettier स्वभाव से कभी तेज़ नहीं रहा, लेकिन अधिकांश uses के लिए पर्याप्त तेज़ था। यह बात मुझे हमेशा असंतोषजनक लगी, इसलिए कुछ करना चाहता था। friendly competition से बेहतर तरीका क्या होगा। 9 नवंबर को, मैंने ऐसे Rust project के लिए $10k bounty रखी जो Prettier test suite का 95% पास करे”
    कोई चीज़ Rust में लिखी गई है, इस तथ्य से बेहतर performance कैसे अपने-आप निकलती है, यह समझ नहीं आता। मौजूदा codebase को Rust में बस transpile करके reward लिया जा सकता था

    • “बस” शब्द देखकर लगता है कि उसके बाद आने वाला काम आसान नहीं होगा
      अगर वाकई आसान हो, तो उसे इस तरह qualify करने की ज़रूरत नहीं होती
      इस मामले में JavaScript codebase को Rust में transpile करना आसान है या नहीं, पता नहीं। दोनों languages के thinking model, इस्तेमाल होने वाली libraries और code लिखने के तरीके काफी अलग हैं, और JS-to-Rust transpiler मौजूद भी हो तो Prettier जितने बड़े codebase के लिए पर्याप्त robust होगा, इसमें शक है
    • idiomatic Rust अक्सर मिलते-जुलते दिखने वाले JavaScript/TypeScript code से बिना खास optimization के भी 5–10 गुना तेज़ होता है
      यह काम पर निर्भर करता है और हमेशा ऐसा नहीं होता, लेकिन बहुत string manipulation करने वाले parsers के लिए यह निश्चित रूप से लागू मामला है
    • string processing में Rust, JS से कहीं तेज़ है
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fasta.html
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/knucleotide.html
    • vjeux से मिला जवाब यह था: “आजकल Rust में लिखे बहुत से तेज़ web tools हैं”
      https://twitter.com/Vjeux/status/1722769322299609565
      मुझे यह convincing नहीं लगता, और लगता है vjeux Rust trend पर सवार हो गए हैं

  • विजेता project Biome कुछ साल पहले Babel के creator Sebastian McKenzie द्वारा शुरू किए गए Rome project का fork या rename है
    लगता है sebmck पिछले करीब एक साल से अनुपस्थित हैं, और project resources के कई access rights सिर्फ उन्हीं के पास थे, इसलिए contributors update नहीं कर पा रहे थे और fork करना पड़ा
    आशा है वे ठीक होंगे, और उससे अलग, यह देखकर अच्छा है कि Biome project अच्छी तरह आगे बढ़ रहा है

  • समझ नहीं आता कि Rust ही क्यों ज़रूरी था
    बस “ज़्यादा तेज़ चीज़” नहीं चल सकती थी? क्या Rust implementation वाकई तेज़ है? Prettier जैसे program में memory safety या leaks जैसी चीज़ें सच में इतनी अहम हैं या नहीं, इस पर भी संदेह है

    • खासकर HN पर ऐसे लोगों की आवाज़ काफ़ी मज़बूत है जो मानते हैं कि Rust इस समय सबसे तेज़ और सुरक्षित language है
      इसलिए कुछ हद तक यह “अगर आप ऐसा कहते हैं, तो खुद साबित करके दिखाइए” वाला bounty challenge रहा होगा

  • जानना चाहूँगा कि Biome benchmarks कहीं उपलब्ध हैं या नहीं
    Prettier की तुलना में performance ठीक-ठीक कितनी बेहतर है?

    • यहाँ कुछ मिला: https://github.com/biomejs/biome/blob/main/benchmark/README.md
      वे 25x का दावा करते हैं, लेकिन आंकड़े पुराने हैं, इसलिए अब जब बहुत सारे features जुड़ चुके हैं, तब भी इसे वैसा ही माना जा सकता है या नहीं, पता नहीं। फिर भी अगर यह उसके आसपास भी है, तो यह बहुत बड़ी उपलब्धि है