# Unreleased features को अपने public bundle से बाहर रखें

Flag names, route strings और unreleased UI text आपकी किसी घोषणा से पहले हर visitor तक पहुँच जाते हैं, और लोग releases के बीच bundles का diff करते हैं। क्या हटाएँ, क्या protect करें, और क्या build से पूरी तरह बाहर रखें।

Source: https://www.afterpack.dev/hi/docs/use-cases/unreleased-features

आपके bundle में उन features का code है जिनकी आपने घोषणा नहीं की है, और वह आने वाली चीज़ों के preview की तरह पढ़ा जाता है।

## Flag names और route strings एक changelog की तरह पढ़े जाते हैं

Flag names, route strings और unreleased UI text गलत audience के लिए लिखे गए changelog की तरह पढ़े जाते हैं। लोग releases के बीच आपके bundles का diff करते हैं और लिखते हैं कि क्या बदला। पढ़ने योग्य नाम वाला flag devtools में चालू करके उसका screenshot ले लिया जाता है, इससे पहले कि आपने सार्वजनिक रूप से कुछ कहा हो।

इसमें से किसी के लिए आपके source की ज़रूरत नहीं है। जो bundle हर visitor के browser तक ship होता है, वह देखना चाहने वाले हर व्यक्ति के लिए पहले से वहीं है, चाहे आपने उसका link दिया हो या नहीं।

## Rebuild एक bundle diff के साथ क्या करता है

[`identifiers.rename`](https://www.afterpack.dev/hi/docs/config#identifiers-rename) आपके identifiers का नाम बदलता है और [`strings.encode`](https://www.afterpack.dev/hi/docs/config#strings-encode) आपके literals को encode करता है, इसलिए shipped फ़ाइल में खोजने के लिए कोई `newBilling` नहीं होता और quote करने के लिए कोई unreleased text नहीं। हर build पर एक नया [`seed`](https://www.afterpack.dev/hi/docs/config#seed) पूरे artifact का आकार बदल देता है, उस code सहित जो नहीं बदला, इसलिए दो releases का diff करना यह देखने का सस्ता तरीका नहीं रह जाता कि नया क्या है।

ज़्यादा मज़बूत जवाब कोई AfterPack setting नहीं है। जो code launch नहीं हुआ है, उसे bundle से बाहर रखना सबसे अच्छा है: server पर तय होने वाला flag, या किसी entitlement check के पीछे एक dynamic import, का मतलब है कि feature ship होने वाली चीज़ में है ही नहीं। कोई preset इसकी बराबरी नहीं करता, क्योंकि artifact में protect करने के लिए कुछ बचता ही नहीं।

## जो रहता है उसे protect करें, जिसे रहने की ज़रूरत नहीं उसे हटाएँ

जो code bundle में रहता है, उसके लिए पूरी build पर preset बढ़ाएँ, या उस module को चिह्नित करें जिसमें unreleased feature है:

```ts
/* @afterpack preset=hard */
export function renderNewBillingFlow() {
  // unreleased UI
}
/* @afterpack end */
```

पहले पूरे bundle पर [`preset`](https://www.afterpack.dev/hi/docs/config#preset) `medium` या `hard` इस्तेमाल करें। किसी एक module को ऊपर उठाने वाले directive के लिए [Pro](https://www.afterpack.dev/hi/docs/tiers) चाहिए। जब preset का पायदान आपकी चाही granularity नहीं देता, तो [`complexity`](https://www.afterpack.dev/hi/docs/config#complexity) target को सीधे सेट करता है।

## पुष्टि करें कि unreleased module कवर है

[Protection Map](https://www.afterpack.dev/hi/docs/protection-map#how-to-read-it) खोलें, जो [`protectionMap.enabled`](https://www.afterpack.dev/hi/docs/config#protectionMap-enabled) चालू होने पर लिखा जाता है, और पुष्टि करें कि unreleased module आपके अपेक्षित target पर कवर है। अपने deploy पर [`sourceMap.enabled`](https://www.afterpack.dev/hi/docs/config#sourceMap-enabled) बंद रखें: published map आपके मूल नाम और strings वापस दे देता है, चाहे उसके बगल की फ़ाइल किसी भी preset से build हुई हो।

## Client-side flag अब भी क्या कर सकता है

Renaming, encoding और हर release में नया build आकार होने से bundle अब changelog की तरह नहीं पढ़ा जाता, और दो versions का diff करना अंदर पहुँचने का सस्ता तरीका नहीं रह जाता। जिस flag को client चालू कर सकता है, उसे नई build को ध्यान से पढ़ने वाला व्यक्ति फिर भी ढूँढकर चालू कर सकता है। जो कुछ भी वास्तव में embargo में है, वह एक ऐसे server response के पीछे होना चाहिए जो तय करे कि feature चलेगा भी या नहीं।

## आगे

- [Presets](https://www.afterpack.dev/hi/docs/presets): `minify` से `extreme` तक की सीढ़ी और हर पायदान का complexity target।
- [Directives](https://www.afterpack.dev/hi/docs/directives#what-to-mark): ऊँचे preset पर और क्या चिह्नित करने लायक है।
- [Protection Map](https://www.afterpack.dev/hi/docs/protection-map#how-to-read-it): पुष्टि करना कि directive ने असर किया।