@ aldo-roman:

Hola Sean de webpack

• No es una _ sugerencia_ hacerlo. Es la única forma de hacerlo si va a consumir momentjs con webpack en su formato de módulo actual.

• Si desea otra solución, envíe un momento de reescritura de PR js desde el formato de módulo AMD a ESM. O quizás incluso contribuir con una especificación de diseño para la reestructuración. El punto es que lo que ha enviado no es procesable.

Moment no tiene control sobre si tiene o no la capacidad de configurar el paquete web. Así que te recomiendo encarecidamente que si realmente amas el momento y quieres usarlo, contribuyas para impulsarlo <3.

Equipo de Moment: Apoyo totalmente el cierre de este problema.

Bueno, eso lo cubre entonces.

Gracias @TheLarkInn. Además, WRT:

Estamos usando Angular CLI que no admite la modificación de la canalización.

No sé mucho sobre esto, pero parece algo para abordar con el proyecto Angular CLI. Dudo que el uso del complemento WebPack Ignore para ignorar las configuraciones regionales de Moment sea la única razón por la que uno querría "modificar la canalización".

Bueno, sospechaba que se trataba de la respuesta que obtendría, pero no había nada que perder con intentarlo.

Al menos podría haber un plan para refactorizar momentjs en módulos es6. Es triste ver que esta biblioteca está abandonada. No enviar un PR en ese momento.

El 1 de septiembre de 2017, a la 1:09 p.m., Matt Johnson [email protected] escribió:

Gracias @TheLarkInn. Además, WRT:

Estamos usando Angular CLI que no admite la modificación de la canalización.

No sé mucho sobre esto, pero parece algo para abordar con el proyecto Angular CLI. Dudo que el uso del complemento WebPack Ignore para ignorar las configuraciones regionales de Moment sea la única razón por la que uno querría "modificar la canalización".

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

No iría tan lejos como para decir que esta biblioteca está abandonada. Especialmente considerando las respuestas rápidas que ha visto.

Potencialmente, podría convencerlo de que envíe un problema para su discusión sobre el cambio a los módulos es (si aún no existe) .🙇🙇

@ElLarkInn
Recientemente intenté hacer algunos cambios que harían que el momento fuera más modular recientemente. El rastreador de problemas de este proyecto todavía está activo, pero en realidad no pude motivar a nadie para que revisara los cambios, así que me di por vencido y seguí adelante.

Hay problemas abiertos con respecto a la modularización: los abrí yo mismo y, por lo que sé, ninguno de ellos se ha cerrado.

@ aldo-roman
Debería tratar a las personas que mantienen bibliotecas como esta con más respeto. Están ofreciendo su tiempo como voluntarios para hacer esto y no te deben nada. Cuando esté escribiendo un número, debe solicitar cambios, no los exija.

@ovangle : ¿a dónde se fue la rama de su módulo? Puedo encontrar una sucursal de cambio de TS que usted cerró. No tengo nada programado concretamente en mi vida hoy, así que si queremos mover algunos módulos, probablemente se pueda hacer.

Además, si la gente se pregunta, @ mj1856 y yo básicamente hemos redirigido nuestro tiempo de código abierto para obtener una biblioteca estándar decente para Date en JavaScript. Consulte tc39 / temporal-proposition y https://github.com/maggiepint/temporal-shim . Dado que esto implica días de viaje para llegar a las reuniones del comité TC39 para mí, no puedo dedicar mucho tiempo a analizar los problemas del momento. Sin embargo, es de esperar que el resultado final sea mejor para todos.

Agradecería que me ayuden concienzudamente con la calza y las especificaciones.

La rama de cambio de TS es a la que me refería; en realidad, no incluye los cambios del módulo (porque tenía sentido fusionar 2.x antes de comenzar ese trabajo, en lugar de tener que hacerlo dos veces), pero el ts los cambios están relacionados principalmente con la declaración de áreas de funcionalidad que forman la base de la división.

Lo principal que estaba ansioso por fusionarme fueron los cambios de transpilación que hice, redujeron significativamente la cantidad de tiempo que lleva ejecutar las pruebas unitarias, lo que habría sido bueno durante la fusión.

Sin embargo, no estoy tan entusiasmado con volver a trabajar en ello. Mis proyectos personales ya no usan el momento y tengo un PR para cambiar dependencias en el trabajo que está casi listo para fusionarse. Si continúo trabajando en ello, invertiría mucho de mi tiempo en una dependencia que en realidad no uso.

PD. Lamento haber desaparecido sin decir nada, pero no estaba seguro de lo que debería haber dicho. Como señalé, todos están ofreciendo su tiempo como voluntarios y no quería apresurarlos, pero tampoco podía justificar el tiempo que estaba tomando para fusionar incluso los cambios más pequeños que no eran controversiales (y mucho menos los cambios más ambiciosos que iba a hacer). make) cuando ya hay proyectos disponibles que satisfacen todas mis necesidades desde una biblioteca de fechas sin los problemas de agrupación que tiene ese momento.

@ovangle , no estamos molestos. Este ha sido un gran obstáculo para todos nosotros. Desafortunadamente, Moment se mete en este lugar de masa crítica donde todo lo que haces, sin importar lo que sea, incluso si debería parecer una "solución" obvia, molesta a alguien. Nos hace más resistentes al cambio de lo que deberíamos ser. No para vencer a un caballo muerto, pero por eso la propuesta temporal. Bien podría arreglarlo para siempre, ¿verdad?

También me encontré con este problema. Estamos usando el momento con Meteor. Y solo en ingles. ¿Existe una forma sencilla de eliminar las configuraciones regionales?

@ aldo-roman Solucioné este problema simplemente rebajando el momento de 2.19.0 a 2.17.1.

Algunos aquí, uso angular-cli y necesito cargar solo moment + locale/pt-br

No puedo creer que esto aún no se haya resuelto, el problema se describió hace más de 1,5 años en diferentes repositorios y problemas

¿Es posible que esté excluyendo toda la dependencia del momento?