सामान्य सवाल — AfterPack क्या है, क्या यह free है, क्या यह आपका app तोड़ता है — landing FAQ पर जवाब दिए गए हैं। यह पेज build-स्तर का विवरण है।
Free और Pro में क्या अंतर है?
Free पूरी pipeline को पूरे bundle पर एक समान चलाता है। Pro निशाना जोड़ता है: आप एक region mark करते हैं और केवल उसी code को भारी treatment मिलता है। Tiers में पूरी matrix और कीमतें हैं।
क्या मुझे framework plugin चाहिए?
First-class framework के लिए, हाँ। Plugin install करें dev dependency के रूप में और एक config लाइन जोड़ें, और आपकी सामान्य build obfuscated output emit करती है। Engine कहाँ चलता है, यह bundler पर निर्भर है: Vite, Rollup, webpack और Parcel bundler की अपनी pipeline के अंदर obfuscate करते हैं, Next.js next build के अंदर एक hook से obfuscate करता है, और esbuild व Angular अपनी build लिख लेने के बाद एक pass चलाते हैं।
$ npm install -D @afterpack/vitePure-bundler या zero-plugin stacks के लिए, इसके बजाय CLI को अपने build output पर point करें:
$ npx afterpack@latest dist/दोनों ही तरह से, AfterPack सख़्ती से post-build, आपके built output पर चलता है। Build directory देना वैकल्पिक है: न दें, तो CLI आपका build output खुद पहचान लेता है। Plugin-supported frameworks पर CI और manual एक-बार के runs के लिए भी CLI ही तरीका है।
एक ही code हर build में अलग output क्यों देता है?
यह per-build polymorphism है, और यही मुख्य बचाव है। डिफ़ॉल्ट random seed के साथ, एक ही input की दो builds संरचना में अलग निकलती हैं। जो static deobfuscator build N का आकार सीखता है, उसे build N+1 के लिए दोबारा इस्तेमाल करने लायक कुछ नहीं मिलता, इसलिए production को समय-समय पर दोबारा build करना attacker की प्रगति को बार-बार शून्य पर लाता रहता है।
जब आपको एक जैसे bytes चाहिए, CI cache hits या golden-snapshot tests के लिए, तो seed को --seed से pin करें:
$ npx afterpack@latest dist/ --seed=gitRelease model: तेज़ iteration के लिए dev builds un-obfuscated रहती हैं; production obfuscated artifact को एक बार build करता है और वही bytes qa, preprod और prod में promote करता है। देखें Builds & CI।
क्या Free सिर्फ़ renaming है?
नहीं। Free पूरा engine चलाता है। डिफ़ॉल्ट light preset identifiers को rename करता है और हर उस string literal को encode करता है जिसे वह फिर से लिख सकता है। medium और ऊपर, Free control flow को flatten भी करता है, logic को fuse और inflate करता है, और constants को materialize करता है, सब कुछ एक फ़ाइल के भीतर। उस output की संरचना बदली जाती है, सिर्फ़ नाम नहीं, और यह polynomial-injective reversal class में रहता है: मूल संरचना केवल असली मेहनत से recover की जा सकती है, और यह मेहनत हर build पर दोबारा करनी पड़ती है।
क्या directive केवल एक लाइन पर असर करता है?
नहीं। Directive एक पूरे region का scope तय करता है, सिर्फ़ अपनी लाइन का नहीं। किसी function के ऊपर वाली लाइन पर अकेले /* @afterpack preset=hard */ से block खोलें और closing brace के बाद /* @afterpack end */ से बंद करें, तो यह body समेत पूरे function को कवर करता है:
/* @afterpack preset=hard */
export function checkLicense(token: string) {
// the entire function body is covered
}
/* @afterpack end */यह block रूप है: अपनी लाइन पर अकेला एक opener, जिसे मेल खाने वाला /* @afterpack end */ बंद करता है। एक अकेले value के लिए, inline /* @afterpack preset=extreme */ अपनी लाइन के बाकी हिस्से को कवर करता है, यानी ठीक उसके बाद वाले literal या expression को। पूरे grammar के लिए Directives देखें।
अगर Pro cloud down हो तो क्या होता है?
यह backoff के साथ retry करता है, फिर fail closed होता है: cloud outage आपकी माँगी गई सुरक्षा से कम सुरक्षा ship करने के बजाय CI को तोड़ देता है।
अगर आपको build path में कोई भी third-party dependency नहीं चाहिए, तो Free को local पर चलाएँ — यह कभी network call नहीं करता। देखें Deployment modes।
Source maps कैसे काम करते हैं?
AfterPack के source maps obfuscated output को आपके मूल source से वापस जोड़ते हैं। वे local debugging के लिए उपयोगी हैं। इन्हें कभी production में ship न करें: एक public .map attacker को उसी source तक सीधा रास्ता दे देता है जिसे आपने अभी obfuscate किया।
AfterPack डिफ़ॉल्ट रूप से उन्हें आपके production bundle से बाहर रखता है: production build पर source-map emission बंद रहता है, //# sourceMappingURL= comment हटा दिया जाता है, और आपके bundler के लिखे source maps मिटा दिए जाते हैं, CSS maps समेत। हर build production है जब तक वह ख़ुद को development न बताए, local npx afterpack भी। देखें Best practices।
क्या मैं CI में AfterPack इस्तेमाल कर सकता हूँ?
हाँ। First-class framework के लिए plugin आपकी सामान्य build के हिस्से के रूप में चलता है, इसलिए आपका मौजूदा build चरण पहले से obfuscated output emit करता है। दूसरे stacks के लिए, post-build चरण के रूप में npx afterpack@latest <path> जोड़ें।
Reproducible artifacts के लिए seed को अपने release identifier पर pin करें, obfuscated output एक बार build करें, और वही bytes अपने environments में promote करें। हर release का audit करें और Protection Map को CI artifact के रूप में जोड़ें। पूरी pipeline के उदाहरण के लिए Builds & CI देखें।
क्या obfuscation मेरे code को धीमा करता है?
थोड़ा। Control flow की संरचना बदलने और constants को दोबारा बनाने से runtime पर काम बढ़ता है, लेकिन एक सामान्य web app पर यह लागत network और rendering के समय की तुलना में आमतौर पर छोटी होती है।
Preset जितना बड़ा, लागत उतनी ज़्यादा: हर पायदान एक ऊँची complexity से जुड़ा है, और default light है। भारी preset ज़्यादा transformation लगाता है; यह सुरक्षा में मापी गई बढ़त नहीं है। Global preset को light पर रखें जब तक कोई भारी preset अपनी लागत के लायक न हो, और extreme को उन regions के लिए रखें जिन्हें आप mark करते हैं। पायदान और उनकी values Presets पर हैं।
API keys और license logic को कैसे protect करूँ?
उन्हें mark करें। किसी secret literal पर inline /* @afterpack preset=extreme */ इस्तेमाल करें, और licensing को gate करने वाले function को /* @afterpack preset=hard */ … /* @afterpack end */ block में लपेटें:
const LICENSE_SECRET = /* @afterpack preset=extreme */ "YOUR_SECRET";
/* @afterpack preset=hard */
export function checkLicense(token: string) {
/* ... */
}
/* @afterpack end */preset=extreme उस region को complexity target 25 तक ले जाता है और string floor को ज़बरदस्ती चालू रखता है, इसलिए literal cleartext में ship होने के बजाय encode होता है। वह फिर भी output में मौजूद रहता है, और program इस्तेमाल के समय उसे दोबारा बनाता है। जिस literal से आपका code तुलना करता है, उसे output से पूरी तरह बाहर रखने के लिए transforms.comparisonHardening.enabled चालू करें: तुलना एक one-way digest check बन जाती है और केवल digest ship होता है। दोनों ही तरह से, जो attacker code को एक instrumented runtime में चलाता है, वह फिर भी value तक पहुँच सकता है (अगला सवाल देखें)। ये directives हर release पर static recovery की लागत बढ़ाते हैं। वे किसी high-value secret को ऐसी चीज़ में नहीं बदलते जिसे client-side रखना सुरक्षित हो। पूरे pattern के लिए Best practices देखें।
क्या मेरा code चलाने वाला कोई secret निकाल सकता है?
हाँ। एक दृढ़ attacker जो आपका code एक instrumented runtime में चलाता है, वह किसी भी ऐसे secret तक पहुँच सकता है जिसे code खुद इस्तेमाल करता है। कोई भी build-time obfuscator इसे नहीं बदलता: अगर चलते हुए program को अपना काम करने के लिए value चाहिए, तो वह उस व्यक्ति को दिख सकती है जो runtime को patch करता है, सही call को hook करता है, या सही पल पर heap का snapshot लेता है।
AfterPack value को सस्ते attacks से अदृश्य बनाता है: static reader और वह blind LLM जो code को चलाए बिना समझाता है। Non-materialization एक gated literal को artifact से पूरी तरह बाहर रखता है, string floor बाकी को cleartext से बाहर रखता है, और per-build polymorphism की वजह से एक build के patterns के लिए लिखे गए tools अगले पर टूट जाते हैं। Code चलाने वाला व्यक्ति फिर भी उसमें इस्तेमाल होने वाली values पढ़ सकता है।
Obfuscation client-side secret की static और re-extraction लागत बढ़ाता है। किसी high-value secret को attacker की पहुँच से बाहर रखने का एकमात्र तरीका है उसे कभी client तक ship न करना: उसे server-side रखें और फ़ैसला server से करवाएँ। preset=extreme उन secrets के लिए इस्तेमाल करें जो सच में server-side नहीं जा सकते, और इसे लागत बढ़ाने वाला मानें, कभी तिजोरी नहीं।
कौन-से frameworks supported हैं?
इन stacks का published plugin है: Next.js, Vite, Webpack, Rollup, esbuild, Astro, Svelte, SvelteKit, Vue 3, Nuxt 3, Angular v17+, Electron और Parcel। Plugin अपनी output directory जानता है, इसलिए उसे कहीं point करने की ज़रूरत नहीं।
Remix और plain JS post-build CLI से चलते हैं, जहाँ directory का नाम आप खुद देते हैं (npx afterpack@latest dist/; Next.js .next/ में लिखता है, Nuxt .output/ में)। पूरी matrix और हर stack के setup के लिए Frameworks देखें, और अगर आप देखना चाहते हैं कि किसी असली bundle पर सुरक्षा कैसी दिखती है तो public Security Scanner देखें।
सवाल कहाँ पूछूँ, bug कहाँ report करूँ या feature का प्रस्ताव कहाँ दूँ?
GitHub पर। सवाल और प्रस्ताव GitHub Discussions में जाते हैं; bugs GitHub Issues में। Security issue public thread के बजाय security@afterpack.dev पर भेजें, देखें SLAs, SLOs & support।
आगे
- Quickstart: कुछ ही मिनटों में install, build, ship
- Tiers: Free बनाम Pro, feature-दर-feature
- Config: हर option, और कौन-सा रूप उसे सेट कर सकता है
- Directives:
@afterpackgrammar और कौन-सी keys लागू होती हैं - Presets: पाँच पायदानों की सीढ़ी
- Best practices: secrets, source maps, और CI