Sweetalert: El proyecto puede ser malicioso

¿Quizás pueda utilizar la integridad de los subrecursos para su caso de uso particular? El apoyo no es

Este también es un problema para mí. Empaqueté mi js y css en varios paquetes. En este momento, no hay un código js noiminified que pueda pasar a mi script gulp. Y no hay forma de que vaya a volcar ciegamente JavaScript ofuscado en el código de mi producto.

Si hay un código no modificado que se pueda revisar, puedo usar esta nueva versión.

También está SweetAlert2, que tiene una versión no minificada disponible. Eso podría salvar algunos problemas. Funciona genial.
https://github.com/limonte/sweetalert2/releases

@daftspunk Gracias por separar este problema de los demás en el n. ° 733

Creo que este problema puede no ser válido ...

Necesito archivos fuente no minificados para poder demostrar que no son maliciosos.

Este proyecto web parece incurrir en malas prácticas, lo que obliga a los usuarios a instalar software en su entorno local para usarlo (npm), lo que los obliga a usar código compilado y ofuscado que no se puede verificar.

Deberíamos crear un nuevo problema o RP "Proporcionar una compilación no confusa en la distribución del paquete". Si eso se rechaza sin una buena razón, entonces podría sospechar que el autor está haciendo algo malicioso.

Si se acepta, puede acceder a los archivos dist, de cualquier versión, minificada o no, a través de unpkg.com

• https://unpkg.com/[email protected]/dist/sweetalert.min.js
• https://unpkg.com/[email protected]/dist/sweetalert.js (PRÓXIMAMENTE, pero con una versión futura de sweetalert, por supuesto)

Mantener los archivos build / dist en el control de origen va realmente en contra de la convención generalizada y causa problemas con las herramientas de Git. Consulte la configuración del proyecto React, por ejemplo. Es extremadamente estándar, ya que los archivos dist se incluyen en la distribución del paquete en npm (verifique la carpeta umd ) y no se incluyen en el repositorio de código fuente en Github .