Tu bundle lleva código de funciones que no has anunciado, y se lee como un adelanto de lo que viene.
Los nombres de flags y las cadenas de rutas se leen como un changelog
Los nombres de flags, las cadenas de rutas y los textos de interfaz no lanzados se leen como un changelog escrito para el público equivocado. La gente compara tus bundles entre versiones y publica lo que ha cambiado. Un flag con un nombre legible se activa desde las devtools y acaba en una captura de pantalla antes de que hayas dicho nada en público.
Nada de eso necesita tu código fuente. Un bundle que llega al navegador de cada visitante ya está ahí para cualquiera que quiera mirarlo, lo hayas enlazado o no.
Qué le hace un rebuild a la comparación de bundles
identifiers.rename renombra tus identificadores y strings.encode codifica tus literales, así que en el archivo publicado no hay ningún newBilling que buscar ni textos no lanzados que citar. Una seed nueva en cada build remodela todo el artefacto, incluido el código que no cambió, de modo que comparar dos versiones deja de ser la forma barata de ver qué hay de nuevo.
La respuesta más sólida no es un ajuste de AfterPack. Lo mejor es dejar fuera del bundle el código que aún no se ha lanzado: un flag decidido en el servidor, o un import dinámico detrás de una comprobación de derechos de acceso, hace que la función no esté en lo que se publica. Ningún preset iguala eso, porque no queda nada en el artefacto que proteger.
Protege lo que se queda, elimina lo que no tiene por qué estar
Para el código que sí se queda en el bundle, sube el preset de todo el build o marca el módulo que contiene la función no lanzada:
/* @afterpack preset=hard */
export function renderNewBillingFlow() {
// unreleased UI
}
/* @afterpack end */Recurre primero al preset medium o hard en todo el bundle. Una directiva que sube un solo módulo requiere Pro. complexity establece el objetivo directamente cuando el peldaño de un preset no es la granularidad que quieres.
Confirma que el módulo no lanzado está cubierto
Abre el Protection Map, que se escribe cuando protectionMap.enabled está activado, y confirma que el módulo no lanzado está cubierto con el objetivo que esperas. Mantén sourceMap.enabled desactivado en tu despliegue: un map publicado devuelve tus nombres y cadenas originales, sea cual sea el preset con el que se compiló el archivo que tiene al lado.
Qué puede seguir haciendo un flag en el cliente
Renombrar, codificar y dar al build una forma nueva en cada versión hace que el bundle deje de leerse como un changelog, y comparar dos versiones deja de ser la vía barata. Un flag que el cliente puede activar lo puede seguir encontrando y activando alguien que lea el nuevo build con atención. Todo lo que esté realmente bajo embargo debe ir detrás de una respuesta del servidor que decida si la función se ejecuta o no.
Siguiente
- Presets: la escala de
minifyaextremey el objetivo de complejidad de cada peldaño. - Directivas: qué más merece marcarse con un preset más alto.
- Protection Map: cómo confirmar que una directiva tuvo efecto.