Als mijn pakket deze afhankelijkheden heeft
{ "name": "my-package",
"dependencies": { "foobar":"~1.0.3", "baz":"2.0.9" }
En het pakket foobarheeft deze afhankelijkheden
{ "name": "foobar",
"dependencies": { "baz":"^2.0.0" }
en de meest recent uitgebrachte versie van bazis 2.1.0, de eerste run van yarnzal [email protected]in foobar/node_modules.
Hoe dwing ik garen om het [email protected]pakket te gebruiken voor foobar?
Ik heb begrepen dat dit mogelijk zou zijn met npm shrinkwrap(a la deze vraag).
De samenvatting van mijn vraag is waarschijnlijk: Garen maakt herhaalbare, deterministische installaties, maar hoe pas ik die installatie aan?
Antwoord 1, autoriteit 100%
Als je inderdaad een sub-afhankelijkheid hebt die te beperkend is in welke versies het zal accepteren, kun je deze kuntoverschrijven met behulp van garen.
GE-UPDATE BEWERKING:Garen nu, vanaf 1.0, ondersteunt officieelhet blok “resoluties”. Dus de manier om resoluties te negeren is door een blok zoals dit toe te voegen aan package.json:
"resolutions": {
"package-a": "2.0.0",
"package-b": "5.0.0",
"package-c": "1.5.2"
}
Soms krijg je waarschuwingen voor “incompatibele” versies, maar ik vind dat sommige pakketten (zoals socket.io) overdrevenbeperkend zijn in welke versie ze accepteren, en daarom zal ik graag kiezen de nieuwste versie als het de dingen niet echt kapot maakt.
Oorspronkelijk maar verouderd antwoord hieronder.
Het klinkt alsof de oorspronkelijke vraag niet helemaal correct was, maar de oorspronkelijke vraag wasin feite degene die ik wilde beantwoorden, en ik vond een antwoord, dus hier is het voor het nageslacht:
p>
Ik gebruik de socket.io-bibliotheek en deze heeft component-emitterals afhankelijkheid. Maar het heeft een paar versies die het vereist. Zo zag het garen.lock-bestand eruit voordat ik iets veranderde:
[email protected]:
version "1.1.2"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.1.2.tgz#296594f2753daa63996d2af08d15a95116c9aec3"
[email protected]:
version "1.2.0"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.0.tgz#ccd113a86388d06482d03de3fc7df98526ba8efe"
Dus het bevatte twee exemplaren van de componentzender in mijn klantcode. Ik keek en er leken geen baanbrekende wijzigingen te zijn tussen 1.1.2 en 1.2.0 (of 1.2.1, wat actueel was). Ik heb eerst geprobeerd om het garen.lock-bestand te wijzigen:
[email protected], component-emitter@^1.2.1, [email protected]:
version "1.2.1"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.1.tgz#137918d6d78283f7df7a6b7c5a63e140e69425e6"
Dit werkte, maar het bestand bevat waarschuwingen dat het automatisch wordt gegenereerd, wat inhoudt dat elke afzonderlijke update of elk nieuw pakket dat ik toevoeg deze wijziging ondermijnt. Een beetje zoeken vond de optie yarn --flat, die garen dwingt om niet meer dan één van elk pakket in het hele project te kiezen. Dat lijkt me overdreven, aangezien ik zeker weet dat er gevallen zijn van onverenigbaarheid tussen oudere en nieuwere pakketten. Ik wilde gewoon een overbodig pakket uit mijn klantcode verwijderen, om de download kleiner te maken; Ik wil nog steeds dat de ontwikkelpakketten allemaal correct werken.
Maar in de documenten voor yarn –flatIk heb een verwijzing gevonden naar een “resoluties”-blok dat in package.json kan komen:
"resolutions": {
"package-a": "2.0.0",
"package-b": "5.0.0",
"package-c": "1.5.2"
}
Dus ik probeerde "component-emitter" : "1.2.1"in een nieuw “resoluties” -blok in mijn package.json te plaatsen, en het maakte de component-emitter in feite plat naar 1.2.1 voor alle plaatsen waar het nodig was, en nu heb ik maar één exemplaar in mijn klantcode.
(En nu wordt het blok resolutionsvolledig ondersteund in yarn, dus je hoeft --flatniet eens te gebruiken.)
Antwoord 2, autoriteit 40%
Dit is nu mogelijk met de selectieve versieresolutiefunctievan garen.
Gebruik in het package.jsonvan uw project resolutions:
"resolutions": {
"foobar/**/baz": "2.0.9"
}
Dit overschrijft de pakketversie van foobar(en alle andere pakketten daaronder) van baz, waardoor het versie 2.0.9 wordt.
Antwoord 3
EDIT: dit is nu verouderd, lees in plaats daarvan dit antwoord:
https://stackoverflow.com/a/46615878/2398593
@SomeCallMeTime‘s antwoordis geweldig en dat doen we al een maand op het werk.
Helaas is dit niet meer mogelijk sinds de v0.24.x(zie die commentaar).
Er is een geopende PR op Githubmet een RFC-voorstel om op een eenvoudige manier om die use case af te handelen zonder de gegenereerde lockfile in de gaten te hoeven houden.