Yarn: Agregar paquete sin guardar en package.json

No, esta función se omitió intencionalmente. Se considera peligroso instalar un paquete sin que se refleje en el package.json. ¿Por qué quieres que exista tal cosa?

Del anuncio de Facebook

Eliminamos el comportamiento de "dependencia invisible" de npm instally dividir el comando. Ejecutar yarn add <name> equivale a ejecutar npm install --save <name> .

Solía ​​usar esa función con bastante frecuencia para probar cosas. Especialmente cuando estoy trabajando con una biblioteca que mantengo y necesito instalar una versión local (que crea un file: dep) solo para probar mis cambios antes de crear una versión.

Si bien estoy de acuerdo en que la implementación de npm para hacerlo de forma predeterminada fue una mala elección, creo que esto es algo que puede ser útil cuando se usa explícitamente.

Sí, creo que sería bueno tenerlo con una bandera explícita, actualmente para este todavía se puede usar npm i =) pero solo para deshacerse de la necesidad de npm.

No apoyamos explícitamente esto, ya que es un cambio imperativo a node_module que se eliminaría con yarn install s posteriores, ya que consideramos que package.json y yarn.lock son la fuente de la verdad.

Tenemos una dependencia que no se puede instalar fácilmente en Windows (libxslt), así que:

• Para Windows: los desarrolladores lo descomprimen en sus node_modues
• Para linux: los desarrolladores lo instalan sin guardar (si está en package.json, los desarrolladores que usan Windows no pueden realizar ninguna instalación porque la compilación fallará)

¿Existe una forma limpia de hacerlo utilizando hilo (o alguna forma mejor de lograr este resultado)?

(Sin embargo, estoy de acuerdo con usted en que los paquetes deben reflejarse en el package.json, pero aquí no puedo encontrar ninguna solución limpia)

@GuillaumeLeclerc ¿Qué pasa con yarn add -D xxx y eliminar la entrada del package.json usted mismo?

¿Se eliminará la próxima vez que se agregue otro paquete? No es asi?

@GuillaumeLeclerc Desafortunadamente, sí.

@GuillaumeLeclerc Es posible que desee limpiar su comentario ...

Agregue un argumento como yarn add --no-save para que pueda instalar un módulo sin alterar mi package.json o yarn.lock. A menudo me encuentro en la necesidad de probar módulos antes de comprometerme con ellos.

No puedo usar npm install normales porque obtengo "Se excedió el tamaño máximo de la pila de llamadas". Entonces, el hilo es la única forma viable de instalar.

¡Por favor, no me hagas revertir los cambios en package.json yarn.lock!

Para mí, esto me está molestando porque estoy tratando de instalar un peerDep. Yarn no tiene forma de instalar peer deps durante install así que tengo que hacerlo manualmente. No puedo yarn add <package> sin que se agregue al package.json / yarn.lock. Estoy atascado.

@viveleroi esto suena totalmente correcto. ¿Por qué querría instalar la dependencia de pares sin agregarla a su package.json ?

@hpurmann Porque está duplicando mi peerDependencies en dependencies (o devDependencies si uso --dev ). Si eso es lo que se pretende, ciertamente no es intuitivo.

@hpurmann Quiero

solo agrega --no-save => es tan importante
Necesito omitir una dependencia opcional particular para un paquete específico. No puedo hacer eso con tu hilo. puede ser con la opción --no-save, puedo trabajar con ella

Debido a que yarn link local-pkg no instala las dependencias de local-pkg en la aplicación de host, me gustaría instalarlas directamente pero no guardarlas en la aplicación package.json ya que serán traídas por local-pkg una vez que se publique .

No entiendo por qué los propietarios son tan obstinados sobre esto. Si no ve un uso, no significa que no lo haya. Creo que si la gente lo pide, significa que lo necesita y que no es necesariamente estúpido.
Agregar una opción --no-save opcional resolvería el problema de algunas personas y no generaría ningún inconveniente.

Estoy tratando de usar Yarn para un proyecto NodeJS que se ejecuta en AWS Lambda. Me sorprende un poco que esta función no sea compatible. Mi caso de uso es que necesito instalar aws-sdk en mi entorno de desarrollo local, pero no quiero que se guarde en package.json porque AWS Lambda ya lo tiene instalado en su entorno. Incluir aws-sdk significa que nuestro paquete final estaría inflado.

el enlace de hilo y el agregado de hilo no pueden convivir. yarn add depende de package.json, mientras que yarn link solo vincula los paquetes locales a otra ubicación.

Suponga que está desarrollando un paquete X que depende de Y, usted es el desarrollador de X e Y, por lo que mantiene X e Y localmente y vincula Y al directorio de X. Cuando agrega hilo en X, se borra el enlace a Y.

¿Cómo resuelves esto?

~ Para tales casos, simplemente puede usar los comandos npm para instalar sin crear una huella en el paquete json o yarn.lock: ~

~ npm install [packages ...] --no-save --no-package-lock ~

como @heikomat se indica a continuación, ya que npm5 usa la poda automática después de la instalación (consulte https://github.com/npm/npm/issues/16853 + https://github.com/npm/npm/pull/18921) esto es no es una opción y podría romper completamente su carpeta node_modules.

ok entonces ahora no puedo vivir sin npm entonces

Estaba usando npm install en uno de mis scripts que instala las dependencias de los submódulos locales en los principales módulos node_modules. Esto funciona bien con npm4, pero está completamente roto con npm5, ya que npm5 simplemente decide bombardear algunos paquetes durante la instalación -.- (consulte https://github.com/npm/npm/pull/18921)

Por esa razón, estaba tratando de reemplazar npm install en mi script con hilo, pero realmente no puedo hacer eso, si hilo siempre toca el package.jsons de los submódulos locales durante la instalación, al menos no sin mi guión se vuelve un poco desordenado y "limpiando" después del hilo

Ya tiene la opción --no-lockfile , por lo que hace que la carpeta node_modules no tenga que pensar,
pero los desarrolladores aún necesitan soluciones para mantener el package.json inmutable.

Gracias.

Me gusta cómo cada vez que alguien explica su caso de uso peculiar para instalar un módulo pero no lo graba, los encargados del mantenimiento regresan y recitan su shibboleth. Debe hacer que sea fácil sentirse confiado en su obstinación si puede presentar esta misma solicitud de muchas personas diferentes como si viniera de aquellos que sufren una falla moral. Como compromiso, tal vez podríamos nombrar el interruptor --i-am-a-heritic-and-a-bad-programmer ?

Es triste ver que el único defecto clave que yarn conserva de npm es su antagonismo con cualquier persona ajena a su organización.

Y en mi caso, quería usarlo como una solución para el problema # 4297 :)
Limitar artificialmente a los desarrolladores a hacer cosas puede hacer que su producto sea inutilizable en determinadas situaciones.

Espera, ¿estás bromeando? Esto es una farsa. Deje de dictar cómo debería funcionar cada flujo de trabajo de desarrollador. Esta es exactamente la razón por la que NPM no nos convenía y nos mudamos a Yarn. Esta ideología de que "package.json e yarn.lock deberían ser fuente de verdad" no tiene sentido. Los paquetes deben poder instalarse sin modificar el código fuente. Simple como eso.

Vamos, mantenedores. Es obvio que la comunidad lo necesita realmente. Deje de cerrar la conversación inteligente con una filosofía fuera de lugar y sin filtros.

Ahora encuentro que yarn interrumpe mis pruebas porque tengo módulos en los que necesito probar require y para probar los requisitos, confirmo un módulo de ejemplo en ./node_modules . Yarn está eliminando los módulos de ejemplo cuando ejecuto yarn install . Más pedantería de la "fuente de la verdad", supongo.

caso de uso: la herramienta que uso requiere un paquete. El equipo no usa esa herramienta. Team (justificadamente) no quiere que se instale ese paquete.

Esto es muy frustrante. Uso codelyzer para la guía de estilo angular, pero el resto de mi equipo no lo hace y no afecta la funcionalidad del código. La única forma de hacer que funcione ahora es agregarlo a mi candado de hilo y simplemente asumir que mi candado de hilo no ha cambiado realmente o usar npm a pesar de que mi equipo usa hilo. Ambas son opciones horribles.

Ya es 2018, pero esta función aún no se ha agregado a pesar de los numerosos casos de uso válidos.

Solo para dar otro ejemplo de por qué esto podría ser útil:

Tenemos un script que actualiza automáticamente las dependencias instalando la nueva versión, ejecutando las pruebas y LUEGO guardándola en package.json / *.lock y confirmando ese cambio O retrocediendo si hubo un error. Es mucho más fácil ejecutar yarn nuevamente en lugar de recordar la versión anterior y explícitamente adding nuevamente.

Además, se siente más limpio no mutar su único punto de verdad ( package.json ) antes de estar seguro "absolutamente" de que realmente puede actualizar esta dependencia sin romper una prueba. Por ahora, termina con un package.json (incluso si es temporalmente) que contiene una dependencia que rompe su código.

Hay muchos casos de uso válidos para este problema. ¿Los mantenedores de yarnpkg estarían dispuestos a aceptar un RP si se creara uno?

haciendo ping a

Mientras tanto, uso el siguiente script en la sección scripts de package.json :

"scripts": {
  "install-sneaky-package": "npm install -g sneaky-package && cp -r $(npm root -g)/sneaky-package ./node_modules/sneaky-package"
}

¿Asumo que hay una alternativa para el hilo?

No hay alternativa, npm5 es un desastre como mi vida.

Y no olvide copiar los enlaces simbólicos en la carpeta .bin. ;)

Para mí, chmod 444 package.json y yarn add XXXX --no-lockfile al menos solucionan el problema para el desarrollo y las pruebas locales.
El complemento termina con un error de permiso (esperado), pero el módulo agregado está presente en node_modules después y puedo probar con las dependencias de pares instaladas localmente pero no persistentes en el package.json sino como dependencia de pares.

A veces necesito una biblioteca de depuración temporalmente, como why-is-node-running . Sé que querré deshacerme de él después de un solo uso, y una opción --no-save me permitiría instalar y olvidar, sin correr el riesgo de contaminar mis dependencias.

Estoy usando Lerna, y realmente solo quiero instalar _only_ Lerna en uno de mis pasos de CI, para la etapa de publicación, ya que el proyecto ya está construido en un paso anterior y los artefactos se han transferido. ¿Es ese un escenario válido?

Me ahorraría algunos pasos si esta función estuviera disponible.
Mi node_modules está en .gitignore de todos modos.

En vez de:

git clone external-package (needed for temp testing only)
yarn install
yarn link

volver a mi repositorio original
yarn link external-package

sólo:
original-repo:
yarn install external-package --no-save

Como parte de nuestras canalizaciones de compilación, necesitamos instalar nsp y ejecutarlo, exportando un archivo dependency-check.xml.

No veo por qué la instalación de esta herramienta simple debe reflejarse en la lista de paquetes, solo significa que ahora necesito hacer un git checkout ${BRANCH_NAME} para deshacer las modificaciones antes de poder insertar etiquetas.

No estoy tratando de modificar la fuente. No quiero y no es asunto mío, eso depende de los equipos de desarrollo de mi organización. Estás haciendo mi vida un poco más difícil por alguna filosofía abstracta. Para.

Alguna idea, ¿por qué se ha cerrado este tema? ¿Se ha agregado el interruptor --no-save en un PR?

Hay ocasiones en las que quiero cambiar la versión de un módulo que proviene de una dependencia. Por ejemplo, @types/sinon traído por otra dependencia de desarrollo recientemente rompió mi tsc. No quiero @types/sinon para mis dependencias de desarrollo, pero quiero cambiar manualmente la versión con yarn add @types/[email protected] --no-save para poder seguir trabajando. En cambio, simplemente cambio de nuevo a npm. Super frustrante.

Tengo una dependencia de solo producción (dinámica de aplicaciones) que es en gran medida un truco de binarios específicos de la plataforma. Resulta que ni siquiera lo necesitamos en las máquinas de desarrollo. Agregar yarn add ... --no-save nos permitiría implementar limpiamente sin que el script ponga en peligro el package.json (especialmente porque package.json, desagradablemente, no puede tener comentarios que expliquen el propósito de cada script o dependencia)

cc @kittens @hpurmann

Sírvase abordar este problema increíblemente popular o bloquearlo como resuelto. Sería muy apreciado tener una respuesta concreta a todas las críticas planteadas anteriormente.

Y la comunidad está lista para proporcionar la función, solo háganos saber si acepta dicha solicitud de extracción. Gracias.

jaja, todavía no implementado, niiiiice

¿Por qué quieres que exista tal cosa?

Fue exactamente lo mismo que la gente dijo sobre JSX cuando salió por primera vez mezclando plantillas y lógica. Si es posible y tiene sus casos de uso, la pregunta correcta debería ser ¿por qué no? Quiero decir que es una bandera, no es un comportamiento predeterminado, por lo que le está diciendo hilo explícitamente (también conocido como sé lo que estoy haciendo).

@gatos @hpurmann
Tengo varios paquetes basados ​​en react y estos tienen dependencias de submódulos entre sí. así que reaccioné y reaccioné-dom como un peer-dep pero cuando necesito construir estos paquetes individualmente necesito reaccionar y reaccionar-dom.
Supongo que este sería un caso de uso apto para instalar paquetes localmente sin tener que agregarlos como dep.
No me gustaría tener npm para un uso tan trivial en mi proyecto.
Cualquier actualización, esperando algo similar a --no-save .
Supongo que no hay ningún problema en agregar una función si la comunidad lo exige, asumiendo que el desarrollador es consciente de sus efectos secundarios (perder los paquetes locales tan pronto como ejecute la instalación de hilo).
Gracias

Un truco útil es yarn add --dev pkg && yarn remove pkg . Hace la misma cosa. El archivo de bloqueo permanece como estaba antes de eso, tan intacto.

Esto fue mencionado por @Legends anteriormente, pero vale la pena enfatizarlo:

Una solución para algunos casos es instalar el paquete necesario en una carpeta separada y yarn link el paquete necesario en cualquier lugar donde se hubiera agregado. No es ideal, pero puede ayudar.

cd /third-party
yarn add foo
cd node_modules/foo
yarn link

cd /my-project
yarn link foo

@silentorb definitivamente no vale la pena, en mi humilde opinión. El add + remove es exactamente lo que se hace con el --no-save en npm. No interfiere con los enlaces del sistema y no toca el archivo de bloqueo de mala manera, lo que significa que es lo mismo después de yarn remove .
Sin mencionar que si desea hacer eso mediante programación, definitivamente crear directorios, enlaces, etc.no es el camino a seguir.

algunos casos

¿Por ejemplo? ¿Bastante extraños seguro?

@hpurmann @kittens

Entonces, ¿cuál es la práctica recomendada para desarrollar un paquete con dependencias entre pares?

Si, por ejemplo, tengo React as a peerDependency en mi paquete, ¿debería agregarlo también como devDependency para resolver las importaciones?

Mirando https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json supongo que la respuesta es sí

@ 18 pasos echa un vistazo a https://www.npmjs.com/install-peers

Hay algunas situaciones para utilizar esta función.

Al igual que en el ciclo de vida de CI, agregué un reportero de cobertura. Pero no puedo llevarlos a package.json luego afecta a publicar NPM .

Guardar o no guardar, creo que esta elección debería depender de los propios desarrolladores, no de la herramienta.

Muy bien, intentemos ver esto desde la perspectiva de los mantenedores. Definitivamente puedo ver las desventajas de una solución --no-save ingenua. No obtuvimos una explicación muy completa aquí, pero intentaré construir un hombre de acero. Quizás puedan corregirme. Quizás podamos encontrar un compromiso. @gatos @hpurmann

(Lo siento, esto terminó más de lo que pretendía).

La gestión de dependencias para aplicaciones web y de nodo modernas es un poco caótica. Y, sin embargo, queremos un sistema que nos brinde una automatización confiable y un cierto nivel de control y previsibilidad, con características como la deduplicación y las compilaciones reproducibles.

Para manejar la complejidad, necesitamos saber qué está instalado y por qué, y necesitamos una única fuente de verdad para resolver cualquier inconsistencia. A riesgo de decir lo obvio, node_modules sí mismo no puede cumplir ninguno de esos roles. Es demasiado lento para atravesarlo, demasiado grande para transmitirlo, demasiado detallado para el control de versiones y no puede codificar el aspecto del "por qué". Por eso tenemos package.json y yarn.lock .

Yarn encapsula la complejidad de node_modules dándonos acceso restringido a través de una interfaz. Si prometemos no romper la encapsulación, obtenemos ciertas garantías a cambio, como la deduplicación y las compilaciones reproducibles. Si instalamos cosas en node_modules sin un cambio correspondiente en package.json y yarn.lock , perdemos esas garantías.

Además, ese es un contrato tácito que muchos desarrolladores no conocen explícitamente. Cuando lo rompen, no lo hacen a sabiendas. Entonces, cuando las cosas van mal, se puede culpar injustamente a Yarn. Además, hacer una herramienta con la que sea difícil dispararse no es una mala filosofía de diseño.

Sin embargo , puedo ver varias razones para comprometerme:

• Parece haber una clara necesidad aquí. Solo mire los muchos casos de uso enumerados en los comentarios anteriores y las proporciones de 'pulgar hacia arriba' / 'pulgar hacia abajo'. La aparente terquedad de los mantenedores ante una respuesta tan unilateral no hace que Yarn se vea demasiado bien.

• Se pueden encontrar soluciones que pueden funcionar para todos. Por ejemplo, introduzca un archivo nuevo yarn.local.lock . Los desarrolladores lo pondrían en su .gitignore , y mantendrían un registro de todos los paquetes instalados con la bandera --no-save y sus dependencias.

  Para mantener yarn.lock aislado de esto, se restringe la deduplicación y el aplanamiento del árbol de dependencias 'local'. El archivo de bloqueo local puede adaptarse para coincidir con una versión del archivo de bloqueo principal (y deduplicar en ese caso) pero no al revés. Como resultado, es posible que muchas dependencias locales transitivas no se aplanen en node_modules .

  Con esta solución, Yarn puede seguir realizando un seguimiento de todos los paquetes, los desarrolladores pueden instalar cosas sin contaminar su repositorio y preservamos las compilaciones reproducibles. (También hay espacio para una sección package.local.json con una sección devDependencies , pero no estoy seguro de que sea necesaria).

• Las personas ya están usando soluciones alternativas para obtener lo que quieren de todos modos, al menos tres de ellas se describen en los comentarios anteriores. Pero son incómodos de usar, no ofrecen las mismas garantías y requieren que los desarrolladores luchen contra Yarn para resolverlos. Es lo peor de ambos mundos.

Puede que me haya perdido algo, pero esta parece una conversación que vale la pena tener.

Tengo otro caso de uso: me gustaría que un módulo estuviera disponible en REPL pero no tengo la intención de usarlo en mi código. Tal como está, necesito ir a una carpeta diferente e instalar ese módulo allí, luego importar algunos archivos json usando ../other-project/data/xyz.json .

Pero si quiero importar un módulo y esa cosa importa otros módulos usando rutas relativas, bueno, se romperá.

Dejarme instalar un módulo en node_modules sin guardar lo haría todo mucho más fácil.

Me sorprende lo resistentes que son los mantenedores a esta idea.

Dios mío, acabo de leer los comentarios anteriores y la actitud de los mantenedores es decepcionante. Desarrollo muchos complementos específicos de marcos que tienen dependencias en bibliotecas de marcos y quiero evitar agregarlos como dependencias duras en mis complementos.

Tengo un complemento que se basa en paquetes específicos definidos en peerDependencies , ahora el problema, como muchas otras personas ya han comentado, es cómo diablos instalas las dependencias localmente sin agregarlas al package.json ¿archivo? Bueno, no puedes.

La única solución que he encontrado es instalar peerDepencies como devDependencies cual no se siente ideal en absoluto, pero soluciona el problema. Al menos npm en su horrible estado se instala sin modificar su archivo package.json .

@hpurmann @kittens

¿Ha renunciado a responder a la comunidad? Claramente, ignorar este problema no le está haciendo ningún favor y no va a desaparecer. ¿Cuál es el punto de llamar a esto un proyecto de código abierto si ni siquiera vas a responder la simple pregunta de si alguien hace el trabajo y envía un PR, lo aceptarás?

Probablemente debería haber respondido hace algún tiempo, justo después de que @viveleroi explicara su caso de uso bastante válido (que muchos de ustedes parecen tener). En ese entonces hice un pulgar hacia arriba por su respuesta, que obviamente no es suficiente para ser notado.

Cambié de opinión. Por lo general, la gente quiere muchas cosas y si los encargados del mantenimiento aceptan todas las funciones, el software se hincha. No tengo este caso de uso, pero veo que muchas personas lo quieren.

Aunque no puedo decidir nada. No soy un mantenedor de este proyecto.

@Vheissu ¿Cuál es el problema con yarn add --peer <dep> ?

para mí añadir hilo - parfunciona HASTA que agregue otro paquete, momento en el que los peer deps existentes se eliminan de la instalación local y debe leerlos manualmente.

Me gustaría esta función porque hoy estoy escribiendo una implementación de ejemplo de mi biblioteca usando express, pero ninguno de mis códigos depende directamente de express. No quiero que nada se instale o dependa de Express, pero sí quiero instalarlo en mi directorio actual.

Al igual que @ brendan -hurley
Quiero mantener mis dependencias locales al mínimo para que no tengamos que inflarnos node_modules y nos cueste tiempo y espacio para cada desarrollador que trabaje en el proyecto.

Paquetes que se necesitan en CI pero no localmente:

• Herramientas específicas de CI: semántica-release, greenkeeper-lockfile
• Herramientas de informes de cobertura: cobertura de codacy, overoles
• Herramienta de informes de prueba para CI: jest-junit, etc.

He aquí por qué necesitamos esta función:

El uso de yarn link no vinculará las dependencias del paquete, por lo que debe instalarlas en
el destino vinculado: tener estas dependencias externas agregadas a package.json lo hace mucho más inconveniente.

O yarn link tiene que agregar dependencias o proporcionar una forma de excluir el destino package.json

Tengo un caso de uso bastante esotérico, pero esto me sería útil. Entiendo completamente por qué es importante que yarn.lock y package.json sean la fuente de la verdad, y que si usara un comando --no-save , mis cambios se borrarían en los siguientes yarn comandos.

Dicho esto, deseo que yarn confíe en mí para saber lo que estoy haciendo y me permita pasar la bandera --no-save . Si me encuentro con alguno de los casos problemáticos, sabré exactamente qué salió mal y que solo yo tengo la culpa. :sonreír:

¿Mi caso de uso?
Ejecuto una máquina ganadora de 64 bits.
La máquina de producción es de 32 bits.

La dependencia Node-sass que tenemos solo admite 32 bits a menos que actualicemos el paquete.

No cambiar la dependencia en package.json o yarn.lock para admitir una máquina de desarrollo.
Por lo tanto, me gustaría instalar localmente el último node-sass para admitir 64 bits, pero no afectar el package.json y yarn.lock

Me gustaría instalar paquetes @types/* en proyectos que no sean de TypeScript sin contaminar package.json / yarn.lock para un mejor autocompletado en VSCode.

Yo uso lerna con espacio de trabajo de hilo.
La definición de tipo de Antd se rompe debido a la actualización de @ types / [email protected] .
Antd arreglará esto el fin de semana.
Pero ahora necesito forzar al hilo para que instale una versión fija de @ types / [email protected] en workspaceRoot manualmente sin afectar el package.json actual (ya que instalará la última versión automáticamente).

Mantener el comportamiento predeterminado de guardar en package.json es correcto, pero hay casos reales en los que el desarrollador debe instalar el módulo sin afectar el package.json. Especialmente cuando hay algún cambio inesperado en algunos paquetes.

La actualización implícita del paquete y el guardado implícito en package.json provocan conflictos.

Aquí hay otro caso de uso. Mantengo una biblioteca de React. Antes de publicar una nueva versión, quiero ejecutar mis pruebas con varias versiones de react y react-dom , para verificar que mis cambios sean compatibles hacia atrás y hacia adelante ( @next ). Estaba haciendo esto usando la configuración a continuación, pero ahora quiero usar los espacios de trabajo de Yarn, así que necesito migrar a Yarn.

"test:backwards": "npm i [email protected] [email protected] --no-save && npm test",
"test:forwards": "npm i react<strong i="9">@next</strong> react-dom<strong i="10">@next</strong> --no-save && npm test",
"test:latest": "npm i react<strong i="11">@latest</strong> react-dom<strong i="12">@latest</strong> --no-save && npm test",
"test:compat": "npm run test:backwards && npm run test:forwards && npm run test:latest"

No puedo hacer que este script cambie mi package.json ya que eso haría que mi comando de publicación ( pack publish ) fallara debido a cambios no establecidos.

Quiero agregar paquetes adicionales en mi canalización de CI para propósitos de prueba sin tocar el archivo package.json (podría ser un montaje de archivo de solo lectura).
Estos no son parte de los componentes de desarrollo.
Durante el desarrollo y las pruebas en las máquinas de desarrollo, no se instalarán y durante la compilación y producción no se instalarán, solo son necesarios y aceptables en el servidor de CI durante las pruebas.

Esto funciona simplemente usando npm, pero el hilo debería poder eliminar la dependencia de npm.
Esto muy bien podría hacernos volver a usar npm solo en lugar de solo hilo.

Además, simplemente rompe la promesa de que el hilo pueda reemplazar completamente a npm, porque simplemente no puede hacer lo que npm puede.

Además, sí, oculte absolutamente esta característica detrás de alguna bandera porque este no debería ser un caso de uso normal, sino un caso de uso de borde.

Estás bromeando ? 3 años para agregar un simple cambio?

Otro caso de uso: utilizamos un paquete npm ( git-hoooks ) para las comprobaciones previas a la confirmación. No todos en el equipo tienen un nodo instalado, por lo que incluirlo en package.json rompería las confirmaciones para algunas personas. Así que estoy tratando de crear scripts npm para habilitar / deshabilitar transitoriamente los ganchos instalando / eliminando git-hooks. Muy decepcionado al descubrir que esta tarea aparentemente simple y fácil es prácticamente imposible de lograr con hilo.

Si la preocupación es que yarn.lock ya no será una fuente de verdad para el contenido de node_modules, bueno, ¿qué tiene de malo eso? ¿No podrían las funciones existentes simplemente ignorar la existencia de las dependencias sin seguimiento? Yarn es una gran herramienta y los encargados del mantenimiento han prestado un gran servicio a la comunidad de JS, pero deben reconsiderar esta decisión.

Estás bromeando ? 3 años para agregar un simple cambio?

@spanasik y @Ryuurock : sea cortés cuando

Esto no ha llevado "3 años" porque el cambio es demasiado complicado de implementar, es porque los mantenedores no están convencidos de que será un beneficio neto para los usuarios. Si no está de acuerdo con esto, defienda la función.

@NickHeiner aquí hay 10 pantallas de argumentos. Y lo principal que genera frustración no es que los mantenedores no estén convencidos, sino que lo ignoran, no responden a los argumentos, cuando la gente "no está de acuerdo con esto, argumenta a favor de la función". Y cuando la gente se frustra, por supuesto, deja comentarios desagradables. Por favor, no culpe de todo a los usuarios.

Estoy de acuerdo en que sería mejor si los mantenedores abordaran la discusión aquí. Hay un claro interés de un amplio grupo de personas durante varios años. Entonces, quizás mi sugerencia de que @spanasik y @Ryuurock deberían simplemente "presentar un argumento" no es razonable, porque probablemente se ignoraría como todo lo demás aquí.

Y cuando la gente se frustra, por supuesto, deja comentarios desagradables. Por favor, no culpe de todo a los usuarios.

Estoy en desacuerdo. Esta grosería todavía no es un paso útil ni un comportamiento aceptable entre los adultos. Ser descortés es una excelente manera de justificar que los mantenedores ignoren esto aún más: "el hilo son solo trolls".

Formas constructivas de avanzar:

1. Llame la atención del mantenedor a este hilo en otros canales (tal vez lo hayan ignorado) y pídales que al menos reconozcan los argumentos aquí, incluso si no están de acuerdo.
2. Bifurque / reemplace el hilo y gobierne el proyecto de una manera con la que la gente esté más feliz.

Un truco útil es yarn add --dev pkg && yarn remove pkg . Hace la misma cosa. El archivo de bloqueo permanece como estaba antes de eso, tan intacto.

Probado - no funciona.

Mi caso de uso es el siguiente:
Algunos paquetes tienen complementos opcionales que se cargan con 'require'. No quiero agregar estos complementos a la sección devDependencies, así que hago un 'yarn add my-add-in' y lo elimino manualmente del archivo package.json. En mi canalización de CI en la nube, uso 'npm i' los agrego (para probar). En mi canalización local no quiero usar npm porque crea un archivo de bloqueo adicional. Mi mejor opción ahora es usar npm y luego eliminar su archivo de bloqueo (para eliminar la segunda versión que aparece de la verdad).

Entonces, después de leer todo, mi pregunta a los mantenedores es esta:

• ¿Por qué eres tan inconsistente?
• ¿Por qué no implementar esta filosofía en todas las funciones?
  
  
  
  • Es decir: decidir cómo se deben hacer las cosas para todos nosotros y eliminar todas las demás opciones de todas las funciones. ¡Mantener el rumbo! ¡Permanecer fiel a ti mismo!
  
  

El hecho innegable es que todo buen software tiene ajustes de configuración porque un buen software permitirá al usuario elegir lo que es mejor para su situación . Y tocar siempre el archivo 'package.json' es una buena práctica, pero existen casos extremos en los que 'yarn' simplemente no está a la altura de la tarea debido a esta filosofía.

Me gusta mucho el hilo porque es simple y rápido . Es realmente desafortunado que los mantenedores estén librando una batalla que seguramente perderán, porque la comunidad se ve obligada a volver a un npm lento y confiable para que las cosas funcionen.

Bajemos un poco la temperatura. Nadie necesita sentirse disgustado por un
software que pueden utilizar de forma gratuita.

El miércoles 15 de enero de 2020 a las 23:17 Hajime Yamasaki Vukelic <
[email protected]> escribió:

Me disgusta que el hilo me haga trabajar de cierta manera. me gusta
decidir las cosas por mi cuenta, y no me gusta cuando mis herramientas me dicen cómo
debería funcionar, el insulto a mi inteligencia es el menor de los problemas, y
no poder hacer las cosas siendo, con mucho, el más grande.

Creer en reglas perfectas y que nunca habría una ocasión para
romperlos es ingenuo. Existe una diferencia entre las "mejores prácticas" y
"Haz o muere". Como dice Oliver Wendell Holmes Sr.:

El joven conoce las reglas, pero el anciano conoce las excepciones.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTAZRWD3XJQEGH5N5RL3Q6ACZNA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVDVREXG43VMDM57 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA
.

Crea tu propio administrador de paquetes, nadie te obliga a hacer nada.

No enojado en absoluto, solo señalando el error en su lógica:

el hilo me hace trabajar de cierta manera.

Yarn no te obliga a hacer nada, han creado una herramienta (gratis) y funciona de cierta manera. Si no te gusta, usa otra cosa.

@foxbunny Te agradezco que

Incluso si cree que es razonable y simplemente se siente disgustado en este caso, no creo que el lenguaje sea una forma educada de hablar con las personas que han creado esta herramienta disponible gratuitamente para usted. Puede dar comentarios constructivos sin dejar de ser respetuoso.

@whitecolor el equipo tiene un punto. Esa opción, guardar es estúpida. Yarn garantiza el equilibrio entre node_modules, package.json y el archivo de bloqueo y eso es genial. Eso es más seguro ... el npm --save es peligroso. Me decepciono muchas veces

Por favor para

O qué tal si todos usan la herramienta que funciona de la manera que creen que es mejor y se calman.

Mi caso de uso es

Quiero actualizar la subdependencia de nuestra aplicación.
Vinculo esta dependencia con yarn link
Luego utilizo uno vinculado en nuestra aplicación
Agrego alguna dependencia en nuestra biblioteca
La dependencia de lib agregada no se instala en la aplicación principal después de yarn install (wtf no.1)
Luego pienso, está bien, agreguemos rápidamente sin guardar en la aplicación para poder verificar si las cosas funcionan antes de publicar la actualización en nuestra biblioteca.
Pero no.

Gracias

Lamento ver que los autores ignoran a la comunidad.

Como voluntario de código abierto, es necesario tener una filosofía coherente o la
El proyecto se degradará hasta convertirse en una bola de barro. Esto significa a veces decir
la gente "no". Si no está de acuerdo, puede crear su propio paquete
gerente, al igual que el hilo reemplazó a npm.

El martes, 3 de marzo de 2020 a las 03:53 Artur Kwiatkowski [email protected]
escribió:

Lamento ver que los autores ignoran a la comunidad.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTA4K3STUMXFRUDMPJU3RFTVTLA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXP63JWWWK3TUL52HS4DFVREXG43KSMVNW5 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA
.

Estoy usando Lerna, y realmente solo quiero instalar _only_ Lerna en uno de mis pasos de CI, para la etapa de publicación, ya que el proyecto ya está construido en un paso anterior y los artefactos se han transferido. ¿Es ese un escenario válido?

^ mi comentario original: honestamente, no sé por qué necesitaría esto, y no sabía que este hilo explotaría tan horriblemente, pero es divertido ver correos electrónicos sobre él años después.

Me inclino a estar de acuerdo con los mantenedores aquí:

1. Mi propio argumento no me convence. Supongo que los mantenedores estaban siendo educados al no criticarlo por ser un argumento estúpido.
2. Incluso si alguien _subiere_ un PR, significaría que el mantenimiento continuo de la función sería la carga adicional para los mantenedores, impidiéndoles mantener el producto principal.
3. Este tipo de característica sería mal utilizada por novatos sin pretensiones y / o consumidores de hilo relativamente poco calificados, perpetuando aún más el punto 2.

En cualquier caso, probablemente exista una forma mejor y más sólida desde el punto de vista arquitectónico de mitigar la necesidad de esta función.

Creé yarn-add-no-save para lograr esta funcionalidad. Se puede instalar localmente en su proyecto o globalmente:

$ yarn add yarn-add-no-save --dev
# or
$ yarn global add yarn-add-no-save

Una vez instalado, simplemente puede ejecutar:

$ yarn add-no-save <packages> # (yarn-add-no-save when installed globally)

Mi caso de uso es probar módulos que declaran peerDependencies para que la herramienta tenga algunas opciones para instalarlos automáticamente, para ver todas las opciones ejecutadas:

$yarn add-no-save --help

NOTA: Soy consciente de que guardar un paquete para instalar paquetes sin guardarlos es irónico y básicamente frustra el propósito, pero esto es lo mejor que pude encontrar y se adapta a mis necesidades.

Esto es muy útil, especialmente el soporte de peerDeps. Gracias.

Hay varios buenos argumentos para esta función. No es como hacerlo por defecto, la gente está pidiendo que esté detrás de una bandera clara que solo las personas que lo necesiten lo usarán. Actualmente, como otros, necesito hacer algunas pruebas durante CI con otras versiones de la biblioteca que no quiero guardar . No puedo entender qué es tan difícil de entender aquí.

Tengo que yarn install xxx luego yarn remove xxx .

No estoy seguro si este caso de uso se discutió alguna vez. Permítanme intentar explicar mi situación: tengo un montón de paquetes interdependientes entre sí en un repositorio. Todos usan las mismas dependencias externas con un paquete común en los subproyectos de servicio raíz debajo, cada paquete local debe construirse en el orden para que se consuma el siguiente. Estoy tratando de usar espacios de trabajo de hilo para esto. Para empezar, no tengo ningún paquete local definido en mi root package.json. Después de un ciclo completo de compilación de todos los componentes, termino teniendo un root package.json completamente actualizado con esas dependencias locales. Ahora, cuando este actualizado se construya en CI, todos los paquetes locales agregados fallarán debido a la falta de disponibilidad. Tenemos que eliminar esas entradas recién agregadas para que funcione en CI.

Tengo que yarn install xxx luego yarn remove xxx .

lo mismo

Aquí hay un caso de uso para querer poder hacer esto:

Estamos creando una herramienta con un ecosistema modular para "dispositivos" dentro de la herramienta, y el plan es configurar una instancia local con esos dispositivos y activarlos dinámicamente mediante la configuración. Los dispositivos se publican en npm (y podrían invocarse fuera de nuestro marco si alguien quisiera).

El proyecto vanilla NO depende de estos paquetes, por lo que ahorrar hasta package.json sería inapropiado. La configuración de una instancia específica puede requerir que uno de los paquetes se instale localmente.

La falta de esta característica parece ser una decisión limitante para nuestro proyecto, aunque continuaremos explorando enfoques alternativos.

Antes de leer la respuesta de "mantenedores" aquí, pensé que era la persona más obstinada de todos los tiempos.

Casi 4 años ... 🤦

No es lo mismo "terquedad" que "tener una visión de diseño y no implementar todo lo que alguien pide".

No es lo mismo "terquedad" que "tener una visión de diseño y no implementar todo lo que alguien pide".

La visión del diseño describe el camino feliz y las escotillas de escape como la que se solicita aquí, se suman a la utilidad para la comunidad en general.

¿Por qué no simplemente agregar una sección al archivo de bloqueo que realiza un seguimiento de las instalaciones de "forma libre" y las instantáneas incrementales del status quo (en node_modules ), para que sean reversibles de forma segura? O tal vez coloque las dependencias en una carpeta separada de node_modules, y use node_modules solo para mantener los enlaces expuestos a su paquete, para que Yarn pueda administrar las cosas por sí solo y no preocuparse por las instalaciones invisibles que sobrescriban y rompan las cosas.

Git resolvió este problema décadas antes que tú, ¡ponte al día! ¡Solo piensa en algo! Eso es lo que es el diseño: eludir las limitaciones, en lugar de luchar contra ellas (o ceder a ellas).

La visión de túnel en ambos extremos aquí nace de la ignorancia, el pensamiento excesivo y la polarización innecesaria. No hay artes marciales, ni filosofía, ni revolución, ni política; solo hay una herramienta, un montón de código y un trabajo por hacer. Si la herramienta no puede ayudar a hacer el trabajo, no es una herramienta para ese escenario en particular. Y para una herramienta que pretende ser un reemplazo completo de propósito general, como Yarn, hay tantos escenarios comunes que se descuidan aquí que simplemente está cavando su propia tumba.

Siento que todo el mundo se empuja unos contra otros por una colina estrecha cuando podíamos rodearla.