En mi paquete.json:
"dev": "parcel parcel/index.scss parcel/index.js --dist-dir assets --no-source-maps", "build": "parcel build parcel/index.scss parcel/index.js --dist-dir assets --no-source-maps" dev . Obtengo los resultados esperados, que son mis dos archivos de índice que se colocan en la raíz de mi carpeta de activos y ambos se completan con código. Puedo ver mi Sass y JS provenientes de archivos separados.
build también generará ambos archivos de índice, sin embargo, el archivo js está vacío. El archivo css está poblado.
Sin errores. Construcción completa.
Todas las demás configuraciones son predeterminadas.
Estoy en una computadora portátil Win10 que ejecuta el último nodo y npm.
¿Algunas ideas?
Aquí hay una versión simplificada de lo que está sucediendo:
Su archivo de parcel/index.js tiene líneas como esta:
import './scripts/global/global'; ... Y el archivo ./scripts/global/global tiene elementos que se ven así:
function globalTest1() { console.log('testing from global.js function 1'); } ...Parece que está tratando de crear un paquete que expone un montón de funciones en el espacio de nombres global.
Eso no sucede aquí porque, de forma predeterminada, la parcela intentará crear un paquete moderno basado en ESModule (por ejemplo, algo que podría importarse a un archivo <html> con <script type="module>" ). Las variables declaradas en este tipo de secuencias de comandos, de forma predeterminada, no forman parte del espacio de nombres global (consulte la documentación de mozilla ). Además, en el modo de producción (p. ej., cuando ejecuta la parcel build ), el paquete intenta ser inteligente para eliminar las cosas que puede decir que no se usan dentro del paquete (consulte los documentos de alojamiento del alcance del paquete ). Como no está utilizando ninguna de las importaciones, todas se eliminan.
Parcel v1 solía admitir este escenario con un indicador --global que no se transfirió a v2. Hay un elemento de hoja de ruta a corto plazo para respaldar este escenario a través de un "formato de salida UMD": aún no está completamente implementado, pero cuando lo esté, debería poder definir alguna variable global que contendrá todas las exportaciones de nivel superior de su paquete (ver PR #7240 , PR #7381 y Issue #7312 ).
Mientras tanto, debería poder resolver este escenario asignando explícitamente las cosas que desea que sean el espacio de nombres global a la variable globalThis en el script de entrada. Parcel verá que estos artículos se usan y, por lo tanto, no los sacudirá. Desafortunadamente, el proceso implicaría un poco de repetitivo manual, pero debería desbloquearlo por ahora. Por ejemplo, podría cambiar su archivo de parcel/index.js para exponer todas las exportaciones del archivo global.js en una variable global llamada myGlobalFunctions :
import * as myGlobalFunctions from './scripts/global/global'; globalThis.myGlobalFunctions = myGlobalFunctions; .....(Dependerá de usted elegir un nombre y una estructura para estas exportaciones, en función de su escenario).
Aunque su problema parece estar resuelto, tuve un problema similar con la creación de una biblioteca JS con Parcel 2 (módulo compilado vacío), solo lo estoy notando aquí.
Esta entrada en package.json lo arregló: "main": "dist/index.js" (especifique la ruta al módulo compilado)
Mi módulo contiene declaraciones de export .
Una molestia que surge de esto es que cuando ejecuta una parcela con un objetivo diferente, necesita cambiar o eliminar esta entrada. También puede dejar que el paquete lo ignore ( siguiendo los documentos ) agregando "targets": {"main": false} , pero luego el truco mencionado anteriormente para el objetivo index.js tampoco funciona.