Después de tanto luchar pudimos hallar la respuesta de esta contratiempo que muchos lectores de este sitio web tienen. Si deseas aportar algún detalle no dudes en dejar tu información.
Solución:
Antes de responder las preguntas específicas de Keith, me gustaría preparar el escenario describiendo los fundamentos de los “Proyectos”, los “Directorios de paquetes” y el “Directorio de paquetes predeterminado” de Salesforce DX.
IMPORTANTE: Si no necesita (o no desea) leer la información de “fundamentos”, simplemente desplácese hacia abajo hasta el tercio inferior de esta respuesta. Tengo el bloque de preguntas de Keith citado ahí abajo con las respuestas justo debajo de ellas.
¿Qué es un “Proyecto” de Salesforce DX?
En general, un proyecto de Salesforce DX es una nueva estructura de archivo local que recopila los metadatos de su organización (código y configuración), plantillas de organización, datos de muestra y pruebas. La raíz del proyecto suele ser también la raíz del repositorio de un sistema de control de versiones (VCS).
Específicamente, existe un proyecto SFDX cuando tiene un directorio local que contiene lo siguiente:
- Un archivo de configuración del proyecto. Este archivo siempre se llama
sfdx-project.jsony el directorio donde se encuentra se convierte en la “raíz” de ese proyecto de Salesforce DX. - Uno o más “Directorios de paquetes de Salesforce DX”, que contienen fuente SFDX. Estos directorios se encuentran dentro de la raíz del proyecto SFDX, contienen la fuente SFDX y debe ser declarados explícitamente como “Directorios de paquetes” agregando su (s) ruta (s) a la
packageDirectoriesarray dentro del proyectosfdx-project.jsonexpediente. - Un directorio oculto llamado
.sfdxdonde la CLI de Salesforce mantiene una variedad de archivos y directorios que respaldan la operación interna de la CLI para ese proyecto específico de Salesforce DX.
Hay un par de archivos más que obtiene después de ejecutar el sfdx force:project:create comando, pero la lista anterior describe el conjunto mínimo de archivos y directorios que se requieren para tener un proyecto funcional de Salesforce DX.
¿Qué es un “directorio de paquetes” de Salesforce DX?
La CLI de Salesforce funciona escaneando todos los directorios de paquetes declarados en sfdx-project.json para metadatos de origen SFDX agregados o modificados localmente. Intenta sincronizar esa fuente con cualquier organización temporal a la que apunte la CLI con sfdx force:source:push o sfdx force:source:pull.
Cualquier metadato (objetos personalizados, código Apex, perfiles, etc.) creado fuera de su proyecto SFDX (como en una organización temporal) será nuevo en el mapa interno de la CLI de los metadatos de su proyecto. Cuando esto sucede, la CLI debe tener un lugar para colocar los metadatos recién descubiertos. Aquí es donde entra el directorio de paquetes predeterminado.
¿Qué es el “Directorio de paquetes predeterminado” y por qué es especial?
Definido como parte de un proyecto sfdx-project.json , el directorio de paquetes predeterminado es la ubicación de acceso de la CLI para almacenar metadatos “agregados de forma remota”.
Por ejemplo, si agrega un nuevo objeto personalizado llamado MyObject__c a su organización temporal usando la interfaz de usuario de configuración y luego ejecute sfdx force:source:pull, la CLI guardará la fuente SFDX para su nuevo objeto localmente en su Directorio de paquetes predeterminado.
La ruta a la fuente SFDX para MyObject__c se verá algo como esto:
sfdx-project-dir
└─ sfdx-package-dir
└─ main
└─ default
└─ objects
└─ MyObject__c
├─ fields
└─ MyObject__c.object-meta.xml
Los nombres de sfdx-project-dir y sfdx-package-dir será diferente para su proyecto, pero todo lo demás se vería exactamente así. La CLI de Salesforce siempre utilizará la ruta main/default/ dentro de su directorio de paquetes predeterminado al almacenar metadatos agregados de forma remota. Esto también sucede cuando usa el sfdx force:mdapi:convert comando para convertir la fuente MDAPI a la fuente SFDX.
Sin una ubicación consistente y conocida para que la CLI coloque la fuente SFDX agregada de forma remota, los desarrolladores necesitarían predefinir ubicaciones para todos los tipos de metadatos. Incluso si un desarrollador pensó en “todo” y definió reglas complejas sobre qué metadatos van en un force:source:pull, aún necesitaría un valor predeterminado genérico en caso de que se perdieran algo.
En otras palabras, tener una ubicación predeterminada limpia, simple y coherente para los metadatos agregados de forma remota es una característica, no un error. 🙂
Y ahora, es hora de abordar las preguntas originales de Keith (¡finalmente!)
Ahora que hemos cubierto los fundamentos de los proyectos SFDX y los directorios de paquetes, abordaré cada una de las preguntas originales de Keith, una a la vez.
Pregunta uno: Dos niveles de carpeta (por ejemplo, “principal” y “predeterminado”) parecen redundantes. ¿Por qué tener el nivel “predeterminado”?
miro a main como un módulo dentro de su directorio de paquetes. Aquí es donde iría el conjunto básico de personalizaciones de su organización si es un cliente. Si está creando un paquete administrado, main es donde vive el código “compartido” del que dependen las funciones de su aplicación.
La plantilla SFDX-Falcon utiliza este concepto de metadatos “centrales” y “características” de manera bastante amplia. La idea es que el código / metadatos que pones en un módulo de funciones puede depender de lo que hay en el módulo principal, pero no al revés.
Si es un ISV, la separación lógica de código / metadatos como esta no solo facilita la comprensión y organización de su código empaquetado. También es una forma fantástica de prepararse para el embalaje de segunda generación (embalaje 2).
Entonces, ¿qué pasa con los “redundantes” default directorio dentro de main?
No creo que sea justo llamar al default directorio redundante. Es literalmente el ubicación predeterminada para que la CLI coloque metadatos agregados de forma remota. Puede implementar su propio esquema de organización de código dentro de main, pero se garantiza que la CLI obtendrá una ubicación conocida y coherente para colocar cualquier fuente nueva porque no interfiere con nada “no predeterminado” que pueda estar haciendo.
Finalmente, si se pregunta por qué / cómo podría organizar aún más la fuente SFDX dentro de su main módulo, una sugerencia es implementar un patrón de diseño basado en la “separación de preocupaciones”. Así es como SFDX-Falcon aborda esto:
Fuente: Salesforce DX 201 – Implementación avanzada para ISV (diapositiva 33)
Pregunta dos: Empecé pensando que (para un proyecto más grande) debería tener> más de un directorio de paquetes, por ejemplo, “force-lts” y “force-app”, pero en sfdx-project.json solo uno puede ser nominado como el valor predeterminado que es donde sfdx force: source: pull tira cambios. Así que ahora estoy pensando que sería mejor tener varias carpetas dentro de la única carpeta del directorio del paquete “force-app” que está marcada como o es implícitamente la predeterminada para evitar que se descarguen los archivos en el directorio incorrecto. ¿Qué estructura de carpetas funciona mejor?
La mejor respuesta aquí depende de si es un socio ISV que crea un paquete administrado o un cliente que trabaja en personalizaciones para su organización de producción.
Si eres cliente
Si usted es un cliente con un código base complejo, intrincado y monolítico (también conocido como “Happy Soup”), puede ser útil intentar comenzar a dividir las cosas en muchos paquetes pequeños e independientes no administrados siempre que sea posible. Mejor aún, eche un vistazo a los paquetes controlados por desarrolladores (DCP) que forman parte de Packaging 2 Beta en Spring ’18.
De cualquier manera, está utilizando Directorios de paquetes SFDX separados con la expectativa de que querrá implementar paquetes de forma independiente entre sí como parte de un proceso de entrega ágil regular. Construya rápido, construya en pequeño, implemente con frecuencia.
Si eres un socio ISV
Si es un ISV que crea un paquete administrado de primera generación, todos sus metadatos ya están en un solo paquete (a menos que esté usando paquetes de extensión). Cuando implementa actualizaciones en su organización de empaquetado, normalmente enviará todo a la vez.
La CLI hace que sea fácil de hacer porque sfdx force:source:convert opera en un solo directorio de paquetes durante la conversión de fuente SFDX a MDAPI. Esto hace que sea más fácil para los ISV concentrarse en implementaciones de paquetes completos cuando están listos para enviar código a su organización de empaque.
La buena noticia es que puede organizar la fuente fácilmente módulo dentro de un único directorio de paquetes de todos modos. Todo tu código central entra en main, como describí anteriormente. Para el resto de su aplicación (es decir, sus funciones), agrega una o más módulo de funciones directorios y segmente su código, similar al siguiente.
Fuente: Salesforce DX 201 – Implementación avanzada para ISV (diapositiva 34)
Esto es esencialmente lo que sugiere Keith C cuando dice que “sería mejor tener varias carpetas dentro de la única carpeta del directorio del paquete ‘force-app'”. Todo lo que hace SFDX-Falcon es formalizar una plantilla básica sobre cómo se pueden configurar esas carpetas adicionales.
Sin embargo, existe un inconveniente que surge al organizar su fuente SFDX. El hecho de que hacer un sfdx force:source:pull en metadatos agregados de forma remota, la CLI crea archivos fuente SFDX en
Personalmente, no siento que esto sea un factor decisivo cuando se trata de elegir organizar la fuente SFDX fuera de main/default. Sí, es un inconveniente mover los archivos fuente cuando lo hace, pero los beneficios de tener un código bien organizado (y con suerte bien segmentado) hacen que la inversión valga la pena. De hecho, cuanto más grande y compleja sea la base de su código, más se beneficiará con el tiempo al invertir en organizar las cosas ahora.
Conclusión
Salesforce DX nos brinda una nueva flexibilidad a la hora de organizar los metadatos que usamos para crear aplicaciones o personalizar nuestras organizaciones de producción. Comprender cómo la CLI de Salesforce usa Proyectos SFDX y Directorios de paquetes para sincronizar metadatos con organizaciones temporales puede ayudarlo a aprovechar al máximo su proyecto de Salesforce DX.
El uso de default/main ayuda a la CLI a saber dónde guardar nuevos metadatos. Organizar sus propias personalizaciones en módulos que son hermanos de main dentro de su directorio de paquetes predeterminado puede facilitar la administración de grandes proyectos. Las plantillas de comunidad como SFDX-Falcon brindan un modelo de cómo puede hacer que esto suceda en su propio proyecto, y las inversiones realizadas ahora pueden pagar dividendos más adelante al tener una base de código que sea más fácil de entender y (¡con suerte!) Actualizar.
Según el seminario web mencionado en el comentario, el camino a seguir es dividir los componentes en varias carpetas que tengan nombres significativos. Por ejemplo, sugieren usar el espacio de nombres del paquete administrado prefix como una de las carpetas raíz en el directorio del paquete designado.
No vi ninguna mención explícita de directorios de paquetes únicos o múltiples: probablemente se asume uno.
PD
El trabajo discutido en el webinar es este https://github.com/sfdx-isv/sfdx-falcon-template.
PPS
Sea consciente de esta corriente problema ¿Cómo usar “sfdx force: source: pull” con carpetas distintas a “main / default” donde se agregan componentes en la organización temporal ?.