Yarn: Fügen Sie das Paket hinzu, ohne es in package.json zu speichern

Erstellt am 9. Nov. 2016  ·  96Kommentare  ·  Quelle: yarnpkg/yarn

Es scheint keine Möglichkeit zu geben, das Paket mit Garn zu installieren, ohne package.json zu berühren. (wie npm ohne --save params installieren). Sollte eine solche Funktion nicht hinzugefügt werden?

Hilfreichster Kommentar

Ich verstehe nicht, warum die Eigentümer diesbezüglich so einfühlsam sind. Wenn Sie keine Verwendung davon sehen, heißt das nicht, dass es keine gibt. Ich glaube, wenn Leute danach fragen, bedeutet das, dass sie es brauchen, und sie sind nicht unbedingt dumm.
Das Hinzufügen einer optionalen --no-save -Option würde das Problem einiger Leute lösen und überhaupt keinen Nachteil bringen.

Alle 96 Kommentare

Nein, diese Funktion wurde absichtlich weggelassen. Es wird als gefährlich angesehen, ein Paket zu installieren, ohne sich in package.json zu widerspiegeln. Warum soll so etwas existieren?

Aus der Facebook-Ankündigung

Wir haben das Verhalten "unsichtbare Abhängigkeit" von npm install entferntund teilen Sie den Befehl. Das Ausführen von yarn add <name> entspricht dem Ausführen von npm install --save <name> .

Ich benutze diese Funktion ziemlich oft, um Dinge zu testen. Insbesondere, wenn ich mit einer Bibliothek arbeite, die ich verwalte, und eine lokale Version installieren muss (die eine file: dep erstellt), um meine Änderungen vor dem Erstellen einer Version zu testen.

Obwohl ich der Meinung bin, dass die Implementierung von npm standardmäßig eine schlechte Wahl war, denke ich, dass dies nützlich sein kann, wenn es explizit verwendet wird.

Ja, ich denke, es wäre schön, wenn es erlaubt wäre, es mit einer expliziten Flagge zu tun. Derzeit kann man dafür immer noch npm i =) verwenden, aber nur um npm loszuwerden.

Wir unterstützen dies ausdrücklich nicht, da es sich um eine zwingende Änderung von node_module , die mit nachfolgenden yarn install s gelöscht wird, da wir package.json und yarn.lock als solche betrachten die Quelle der Wahrheit.

Wir haben eine Abhängigkeit, die nicht einfach unter Windows (libxslt) installiert werden kann, also:

  • Für Windows: Entwickler entpacken es in ihren node_modues
  • Für Linux: Entwickler installieren es ohne Speichern (wenn es in package.json ist, können Entwickler, die Windows verwenden, keine Installation durchführen, da die Erstellung fehlschlägt).

Gibt es eine saubere Möglichkeit, dies mit Garn zu tun (oder eine bessere Möglichkeit, dieses Ergebnis zu erzielen)?

(Ich stimme Ihnen zu, dass Pakete in der package.json wiedergegeben werden sollten, aber hier kann ich keine saubere Lösung finden.)

@GuillaumeLeclerc Was ist mit yarn add -D xxx und entfernen Sie den Eintrag aus der package.json selbst?

Wird es entfernt, wenn das nächste Mal ein anderes Paket hinzugefügt wird? Wird es nicht?

@ GuillaumeLeclerc Leider ja.

@ GuillaumeLeclerc Vielleicht möchten Sie Ihren Kommentar bereinigen ...

Bitte fügen Sie ein Argument wie yarn add --no-save damit ich ein Modul installieren kann, ohne meine package.json oder yarn.lock zu ändern. Ich muss oft Module testen, bevor ich mich dazu verpflichte.

Ich kann kein normales npm install da "Maximale Anrufstapelgröße überschritten" angezeigt wird. Garn ist also der einzig praktikable Weg, um zu installieren.

Bitte lassen Sie mich die Änderungen an package.json yarn.lock nicht rückgängig machen!

Für mich beißt mich das, weil ich versuche, einen PeerDep zu installieren. Garn hat keine Möglichkeit, Peer-Deps während install zu installieren, daher muss ich dies manuell tun. Ich kann nicht yarn add <package> ohne dass es dem package.json / yarn.lock hinzugefügt wird. Ich stecke fest.

@ Viveleroi das klingt völlig richtig. Warum sollten Sie die Peer-Abhängigkeit installieren, ohne sie Ihrem package.json hinzuzufügen?

@hpurmann Weil es meine peerDependencies in dependencies dupliziert (oder devDependencies wenn ich --dev ). Wenn das beabsichtigt ist, dann ist es sicherlich nicht intuitiv.

@hpurmann Ich möchte eine Reaktionskomponente veröffentlichen, also sollte die Reaktion ein PeerDep sein. Ich muss jedoch React im Projekt installieren, um es zu entwickeln.

füge einfach --no-save => hinzu, es ist so wichtig
Ich muss eine bestimmte optionale Abhängigkeit für ein bestimmtes Paket überspringen. Ich kann das nicht mit deinem Garn machen. kann mit --no-save Option sein, ich kann es umarbeiten

Da yarn link local-pkg die Abhängigkeiten von local-pkg in der Host-App nicht installiert, möchte ich sie direkt installieren, aber nicht in der App package.json speichern, da sie nach Veröffentlichung von local-pkg bereitgestellt werden .

Ich verstehe nicht, warum die Eigentümer diesbezüglich so einfühlsam sind. Wenn Sie keine Verwendung davon sehen, heißt das nicht, dass es keine gibt. Ich glaube, wenn Leute danach fragen, bedeutet das, dass sie es brauchen, und sie sind nicht unbedingt dumm.
Das Hinzufügen einer optionalen --no-save -Option würde das Problem einiger Leute lösen und überhaupt keinen Nachteil bringen.

Ich versuche, Yarn für ein NodeJS-Projekt zu verwenden, das auf AWS Lambda ausgeführt wird. Ich bin ein bisschen überrascht, warum diese Funktion nicht unterstützt wird. Mein Anwendungsfall ist, dass ich aws-sdk in meiner lokalen Entwicklungsumgebung installieren muss, aber ich möchte nicht, dass es in package.json gespeichert wird, da AWS Lambda dies bereits in seiner Umgebung installiert hat. Das Einbeziehen von aws-sdk bedeutet, dass unser endgültiges Paket aufgebläht wäre.

Garnverbindung und Garnzugabe können nicht zusammenleben. Das Hinzufügen von Garn hängt von package.json ab, während die Garnverknüpfung nur die lokalen Pakete mit einem anderen Speicherort verknüpft.

Angenommen, Sie entwickeln ein Paket X, das von Y abhängt. Sie sind beide Entwickler von X und Y, behalten also X und Y lokal bei und verknüpfen Y mit dem Verzeichnis von X. Wenn Sie Garn in X hinzufügen, wird es gelöscht der Link zu Y.

Wie kommst du darum herum?

~ In solchen Fällen können Sie einfach die npm-Befehle verwenden, um zu installieren, ohne einen Footprint auf dem Paket json oder yarn.lock zu erstellen: ~

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

Wie @heikomat unten angegeben, ist dies der Fall, da npm5 nach der Installation die automatische Bereinigung verwendet (siehe https://github.com/npm/npm/issues/16853 + https://github.com/npm/npm/pull/18921) keine Option und könnte Ihren node_modules-Ordner vollständig beschädigen.

ok also jetzt kann ich dann nicht ohne npm leben

Ich habe npm install in einem meiner Skripte verwendet, das Abhängigkeiten lokaler Submodule von den Hauptknotenmodulen installiert. Dies funktioniert gut mit npm4, ist aber mit npm5 völlig kaputt, da npm5 nur beschließt, einige Pakete während der Installation zu zerstören -.- (siehe https://github.com/npm/npm/pull/18921)

Aus diesem Grund habe ich versucht, die npm install in meinem Skript durch Garn zu ersetzen, aber ich kann das nicht wirklich tun, wenn Garn während der Installation immer die package.jsons der lokalen Submodule berührt, zumindest nicht ohne Mein Skript wird ziemlich chaotisch und "räumt" nach dem Garn auf

Sie haben bereits die Option --no-lockfile , sodass der Ordner node_modules nicht mehr in Betracht gezogen wird.
Entwickler benötigen jedoch noch Problemumgehungen, um package.json unveränderlich zu halten.

Vielen Dank.

Mir gefällt, wie jedes Mal, wenn jemand seinen eigentümlichen Anwendungsfall für die Installation eines Moduls erklärt, es aber nicht aufzeichnet, die Betreuer zurückkommen und ihre Shibboleth rezitieren. Muss es leicht machen, sich in Ihrer Hartnäckigkeit sicher zu fühlen, wenn Sie dieselbe Bitte von vielen verschiedenen Menschen wie von Menschen, die unter einem moralischen Versagen leiden, formulieren können. Als Kompromiss könnten wir vielleicht den Schalter --i-am-a-heritic-and-a-bad-programmer ?

Es ist traurig zu sehen, dass der einzige Hauptfehler, den yarn von npm bewahrt, sein Antagonismus für jeden außerhalb seiner Organisation ist.

Und in meinem Fall wollte ich es als Workaround für das Problem # 4297 verwenden :)
Wenn Entwickler künstlich darauf beschränkt werden, Dinge zu tun, kann Ihr Produkt in bestimmten Situationen unbrauchbar werden.

Warten Sie, veräppeln Sie mich? Das ist eine Travestie. Bitte hören Sie auf zu diktieren, wie jeder Entwickler-Workflow jemals funktionieren soll. Genau deshalb passte NPM nicht zu uns und wir zogen nach Yarn. Diese Ideologie, dass "package.json und yarn.lock die Quelle der Wahrheit sein sollten", ist unsinnig. Pakete sollten installierbar sein, ohne den Quellcode zu ändern. So einfach ist das.

Komm schon, Betreuer. Es ist offensichtlich, dass die Community dies wirklich benötigt. Bitte hören Sie auf, intelligente Gespräche mit ungefilterter und fehlgeleiteter Philosophie zu beenden.

Jetzt stelle ich fest, dass yarn meine Tests unterbricht, weil ich Module habe, in denen ich require testen muss, und um zu testen, muss ich ein Beispielmodul in ./node_modules . Yarn löscht die Beispielmodule, wenn ich yarn install ausführe. Mehr "Quelle der Wahrheit" Pedanterie, nehme ich an.

Anwendungsfall: Für das von mir verwendete Tool ist ein Paket erforderlich. Das Team verwendet dieses Tool nicht. Team möchte (zu Recht) nicht, dass dieses Paket installiert wird.

Das ist sehr frustrierend. Ich verwende Codelyzer als eckigen Styleguide, aber der Rest meines Teams tut dies nicht und es hat keinen Einfluss auf die Codefunktionalität. Die einzige Möglichkeit, es jetzt zum Laufen zu bringen, besteht darin, es meinem Garnschloss hinzuzufügen und einfach anzunehmen, dass sich mein Garnschloss nicht wirklich geändert hat, oder npm zu verwenden, obwohl mein Team Garn verwendet. Beides sind schreckliche Optionen.

Es ist bereits 2018, aber diese Funktion wurde trotz der zahlreichen gültigen Anwendungsfälle noch nicht hinzugefügt.

Um nur ein weiteres Beispiel zu nennen, warum dies nützlich sein könnte:

Wir haben ein Skript, das Abhängigkeiten automatisch aktualisiert, indem es die neue Version installiert, die Tests ausführt und sie dann unter package.json / *.lock speichert und diese Änderung festschreibt ODER ein Rollback durchführt, wenn ein Fehler aufgetreten ist. Es ist viel einfacher, yarn erneut auszuführen, anstatt sich an die alte Version zu erinnern und diese explizit erneut mit adding zu versehen.

Darüber hinaus fühlt es sich sauberer an, Ihren einzelnen Wahrheitspunkt ( package.json ) nicht zu mutieren, bevor Sie "absolut" sicher sind, dass Sie diese Abhängigkeit wirklich aktualisieren können, ohne einen Test zu unterbrechen. Im Moment erhalten Sie ein package.json (auch wenn es vorübergehend ist), das eine Abhängigkeit enthält, die Ihren Code beschädigt.

Es gibt viele gültige Anwendungsfälle für dieses Problem. Wären die Garnpkg-Betreuer bereit, eine PR zu akzeptieren, wenn eine erstellt würde?

pinging @kittens, wenn Sie noch mit diesem Projekt verbunden sind ...

In der Zwischenzeit verwende ich das folgende Skript im Abschnitt scripts von package.json :

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

Ich nehme an, es gibt eine Alternative für Garn?

Es gibt keine Alternative, npm5 ist so chaotisch wie mein Leben.

Und vergessen Sie nicht, Symlinks in den Ordner .bin zu kopieren. ;)

Für mich funktioniert chmod 444 package.json und yarn add XXXX --no-lockfile zumindest um das Problem für die lokale Entwicklung und das Testen.
Das Hinzufügen führt zu einem (erwarteten) Berechtigungsfehler, aber das hinzugefügte Modul ist anschließend in node_modules vorhanden, und ich kann mit lokal installierten Peer-Abhängigkeiten testen, die jedoch nicht in package.json, sondern als Peer-Abhängigkeit bestehen bleiben.

Manchmal benötige ich vorübergehend eine Debugging-Bibliothek wie why-is-node-running . Ich weiß, dass ich es nach einmaligem Gebrauch loswerden möchte, und eine --no-save -Option würde es mir ermöglichen, zu installieren und zu vergessen, ohne das Risiko einzugehen, meine Abhängigkeiten zu verschmutzen.

Ich verwende Lerna und möchte wirklich nur Lerna in einem meiner CI-Schritte für die Veröffentlichungsphase installieren, da das Projekt bereits in einem vorherigen Schritt erstellt und Artefakte übertragen wurden. Ist das ein gültiges Szenario?

Es würde mir einige Schritte ersparen, wenn diese Funktion verfügbar wäre.
Mein node_modules ist sowieso in .gitignore.

Anstatt von:

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

gehe zurück zu meinem ursprünglichen Repo
yarn link external-package

gerade:
Original-Repo:
yarn install external-package --no-save

Als Teil unserer Build-Pipelines müssen wir nsp installieren und ausführen und eine dependency-check.xml exportieren.

Ich verstehe nicht, warum diese einfache Tool-Installation in der Paketliste angezeigt werden muss. Es bedeutet nur, dass ich jetzt ein git checkout ${BRANCH_NAME} ausführen muss, um die Änderungen rückgängig zu machen, bevor ich Tags pushen kann.

Ich versuche nicht, die Quelle zu ändern. Ich will nicht und es geht mich nichts an, das liegt an den Entwicklerteams in meiner Organisation. Du machst mir das Leben für eine abstrakte Philosophie ein bisschen schwerer. Hör auf.

Irgendeine Idee, warum dieses Problem geschlossen wurde? Wurde der Schalter --no-save in einer PR hinzugefügt?

Es gibt Zeiten, in denen ich die Version eines Moduls ändern möchte, die aus einer Abhängigkeit übernommen wird. Zum Beispiel hat @types/sinon das von einer anderen Entwicklerabhängigkeit eingebracht wurde, kürzlich mein tsc gebrochen. Ich möchte nicht @types/sinon für meine Entwicklungsabhängigkeiten, aber ich möchte die Version manuell mit yarn add @types/[email protected] --no-save ändern, damit ich weiterarbeiten kann. Stattdessen wechsle ich einfach zurück zu npm. Super frustrierend.

Ich habe eine reine Produktionsabhängigkeit (Appdynamics), die selbst ein Hack von plattformspezifischen Binärdateien ist. Es stellt sich heraus, dass wir es auf den Entwicklungsmaschinen nicht einmal brauchen. Durch Hinzufügen von yarn add ... --no-save wir eine saubere Bereitstellung durchführen, ohne dass das Skript die Datei package.json gefährdet (insbesondere, da package.json widerwillig keine Kommentare enthalten kann, die den Zweck der einzelnen Skripte oder Abhängigkeiten erläutern).

cc @kittens @hpurmann

Bitte beheben Sie dieses unglaublich beliebte Problem oder sperren Sie es als behoben. Es wäre sehr dankbar, eine konkrete Antwort auf alle oben vorgebrachten Kritikpunkte zu haben.

Die Community ist bereit, die Funktion bereitzustellen. Teilen Sie uns einfach mit, ob Sie eine solche Pull-Anfrage akzeptieren würden. Vielen Dank.

haha, noch nicht implementiert, niiiiice

Warum soll so etwas existieren?

War genau das, was die Leute über JSX sagten, als es zum ersten Mal herauskam, Vorlagen und Logik zu mischen. Wenn es möglich ist und seine Anwendungsfälle hat, sollte die richtige Frage sein, warum nicht? Ich meine, es ist eine Flagge, es ist kein Standardverhalten, also erzählst du Garn explizit (auch bekannt als ich weiß, was ich tue).

@kittens @hpurmann
Ich habe mehrere Pakete basierend auf reagieren und diese haben Submodul-Abhängigkeiten voneinander. Ich habe also als Peer-Dep reagiert und reagiert, aber wenn ich diese Pakete einzeln erstellen muss, muss ich reagieren und reagieren.
Ich denke, dies wäre ein geeigneter Anwendungsfall für die lokale Installation von Paketen, ohne dass diese als dep hinzugefügt werden.
Ich möchte npm nicht für eine so triviale Verwendung in meinem Projekt haben.
Alle Updates, die auf etwas warten, das --no-save ähnelt.
Ich denke, es schadet nicht, eine Funktion hinzuzufügen, wenn die Community dies verlangt, vorausgesetzt, der Entwickler ist sich seiner Nebenwirkungen bewusst (Verlust der lokalen Pakete, sobald Sie die Garninstallation ausführen).
Vielen Dank

Praktischer Trick ist yarn add --dev pkg && yarn remove pkg . Es macht das Gleiche. Die Sperrdatei bleibt so, wie sie vorher war, so unberührt.

Dies wurde bereits von @Legends erwähnt, ist jedoch hervorzuheben:

Eine Abhilfe für einige Fälle ist das benötigte Paket in einem separaten Ordner und installieren yarn link das benötigte Paket zu , wo immer es sonst hinzugefügt wurden. Es ist nicht ideal, kann aber helfen.

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

cd /my-project
yarn link foo

@ Silentorb definitiv nicht wert, imho. Das add + remove ist genau das, was mit dem --no-save in npm gemacht wird. Es wird nicht mit den Systemverbindungen durcheinander gebracht und berührt die Sperrdatei nicht auf schlechte Weise - was bedeutet, dass es nach yarn remove dasselbe ist.
Ganz zu schweigen davon, dass, wenn Sie diese Sache programmgesteuert ausführen möchten, das Erstellen von Verzeichnissen, Verknüpfen usw. definitiv nicht der richtige Weg ist.

manche Fälle

Zum Beispiel? Ziemlich komisch sicher?

@hpurmann @kittens

Was ist die empfohlene Vorgehensweise für die Entwicklung eines Pakets mit Peer-Abhängigkeiten?

Wenn ich zB Reagieren als PeerDependency in meinem Paket habe, sollte ich es auch als DevDependency hinzufügen, um Importe aufzulösen?

Unter https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json denke ich, dass die Antwort ja ist

Es gibt einige Situationen, in denen diese Funktion verwendet werden kann.

Genau wie im CI-Lebenszyklus habe ich einen Berichterstatter hinzugefügt. Aber ich kann sie nicht auf package.json dann NPM .

Speichern oder nicht speichern, ich denke, diese Wahl sollte den Entwicklern selbst überlassen bleiben, nicht dem Tool.

Okay, lassen Sie uns versuchen, dies aus der Sicht der Betreuer zu betrachten. Ich kann definitiv Nachteile einer naiven --no-save -Lösung erkennen. Wir haben hier keine sehr gründliche Erklärung bekommen, aber ich werde versuchen, einen Stahlmann zu konstruieren. Vielleicht können sie mich korrigieren. Vielleicht können wir einen Kompromiss finden. @kittens @hpurmann

(Entschuldigung, das endete länger als beabsichtigt.)

Das Abhängigkeitsmanagement für moderne Knoten- und Webanwendungen ist etwas chaotisch. Und doch wollen wir ein System, das uns sowohl zuverlässige Automatisierung als auch ein gewisses Maß an Kontrolle und Vorhersagbarkeit bietet, mit Funktionen wie Deduplizierung und reproduzierbaren Builds.

Um die Komplexität in den Griff zu bekommen, müssen wir wissen, was installiert ist und warum, und wir brauchen eine einzige Quelle der Wahrheit, um Inkonsistenzen zu beheben. Auf die Gefahr hin, das Offensichtliche zu sagen, kann node_modules selbst keine dieser Rollen erfüllen. Es ist zu langsam zum Überqueren, zu groß zum Übertragen, zu feinkörnig für die Versionskontrolle und kann den "Warum" -Aspekt nicht codieren. Deshalb haben wir package.json und yarn.lock .

Garn kapselt die Komplexität von node_modules indem es uns über eine Schnittstelle eingeschränkten Zugriff gewährt. Wenn wir versprechen, die Kapselung nicht zu unterbrechen, erhalten wir im Gegenzug bestimmte Garantien wie Deduplizierung und reproduzierbare Builds. Wenn wir Dinge in node_modules installieren, ohne eine entsprechende Änderung in package.json und yarn.lock vorzunehmen, verlieren wir diese Garantien.

Darüber hinaus ist dies ein unausgesprochener Vertrag, den viele Entwickler nicht ausdrücklich kennen. Wenn sie es brechen, tun sie es nicht wissentlich. Wenn also etwas schief geht, kann Garn zu Unrecht beschuldigt werden. Außerdem ist es keine schlechte Designphilosophie, ein Werkzeug herzustellen, mit dem man sich nur schwer in den Fuß schießen kann.

Allerdings kann ich mehrere Gründe zu Kompromiss finden Sie unter :

  • Hier scheint es definitiv einen Bedarf zu geben. Schauen Sie sich einfach die vielen Anwendungsfälle an, die in den obigen Kommentaren aufgeführt sind, und die Verhältnisse "Daumen hoch" / "Daumen runter". Die offensichtliche Sturheit der Betreuer angesichts einer solchen einseitigen Reaktion lässt Yarn nicht allzu gut aussehen.

  • Es gibt Lösungen, die für alle funktionieren können. Führen Sie beispielsweise eine neue Datei yarn.local.lock . Entwickler würden es in ihre .gitignore einfügen und alle installierten Pakete mit dem Flag --no-save und ihren Abhängigkeiten aufzeichnen.

    Um yarn.lock isoliert zu halten, ist die Deduplizierung und Abflachung des 'lokalen' Abhängigkeitsbaums eingeschränkt. Die lokale Sperrdatei wird möglicherweise an eine Version in der Hauptsperrdatei angepasst (und in diesem Fall dedupliziert), jedoch nicht umgekehrt. Infolgedessen werden viele transitive lokale Abhängigkeiten möglicherweise nicht auf node_modules .

    Mit dieser Lösung kann Yarn weiterhin alle Pakete verfolgen, Entwickler können Inhalte installieren, ohne ihr Repo zu verschmutzen, und wir behalten reproduzierbare Builds bei. (Es gibt auch Platz für ein package.local.json mit einem devDependencies Abschnitt, aber ich bin nicht sicher, ob dies erforderlich wäre.)

  • Die Leute verwenden bereits Problemumgehungen, um das zu bekommen, was sie wollen, mindestens drei davon sind in den obigen Kommentaren beschrieben. Ihre Verwendung ist jedoch unpraktisch, bietet nicht die gleichen Garantien und erfordert, dass Entwickler gegen Yarn kämpfen, um sie herauszufinden. Es ist das Schlimmste aus beiden Welten.

Ich hätte vielleicht etwas verpasst, aber das scheint ein Gespräch zu sein, das es wert ist, geführt zu werden.

Ich habe einen anderen Anwendungsfall: Ich möchte, dass ein Modul in REPL verfügbar ist, beabsichtige jedoch nicht, es in meinem Code zu verwenden. So wie es aussieht, muss ich in einen anderen Ordner gehen und das Modul dort installieren und dann einige JSON-Dateien mit ../other-project/data/xyz.json importieren.

Aber wenn ich ein Modul importieren möchte und dieses Ding andere Module über relative Pfade importiert, wird es kaputt gehen.

Nur zuzulassen, dass ich ein Modul in node_modules installiere, ohne es zu speichern, würde alles viel einfacher machen.

Ich bin überrascht, wie widerstandsfähig die Betreuer gegen diese Idee sind.

Meine Güte, ich habe gerade die vorherigen Kommentare durchgelesen und die Einstellung der Betreuer ist enttäuschend. Ich entwickle viele Framework-spezifische Plugins, die Abhängigkeiten von Framework-Bibliotheken aufweisen, und ich möchte vermeiden, dass diese als harte Abhängigkeiten zu meinen Plugins hinzugefügt werden.

Ich habe ein Plugin, das auf bestimmten Paketen basiert, die in peerDependencies sind. Jetzt ist das Problem, wie viele andere Leute bereits kommentiert haben, wie zum Teufel Sie die Abhängigkeiten lokal installieren, ohne sie zu package.json hinzuzufügen Datei? Das kannst du nicht.

Die einzige Lösung, die ich gefunden habe, ist die Installation von peerDepencies als devDependencies was sich überhaupt nicht ideal anfühlt, aber das Problem umgeht. Mindestens npm in seinem schrecklichen Zustand wird installiert, ohne dass Ihre package.json -Datei geändert wird.

@hpurmann @kittens

Haben Sie es aufgegeben, auf die Community zu antworten? Es ist klar, dass das Ignorieren dieses Problems Ihnen keinen Gefallen tut und nicht verschwindet. Was bringt es, dies als Open-Source-Projekt zu bezeichnen, wenn Sie nicht einmal die einfache Frage beantworten, ob jemand die Arbeit erledigt und eine PR einreicht? Werden Sie das akzeptieren?

Ich hätte wahrscheinlich vor einiger Zeit antworten sollen, gleich nachdem @viveleroi seinen recht gültigen Anwendungsfall erklärt hatte (den viele von Ihnen zu haben scheinen). Damals habe ich seine Antwort mit dem Daumen nach oben gedrückt, was offensichtlich nicht ausreicht, um zur Kenntnis genommen zu werden.

Ich habe meine Meinung geändert. Normalerweise wollen die Leute eine Menge Dinge und wenn die Betreuer jede Funktion akzeptieren, wird die Software aufgebläht. Ich habe diesen Anwendungsfall nicht, aber ich sehe viele Leute, die ihn wollen.

Ich kann mich aber nicht entscheiden. Ich bin kein Betreuer dieses Projekts.

@ Vheissu Was ist das Problem mit yarn add --peer <dep> ?

für mich Garn hinzufügen --peerfunktioniert BIS Sie ein weiteres Paket hinzufügen. Zu diesem Zeitpunkt werden die vorhandenen Peer-Deps aus der lokalen Installation entfernt und müssen manuell gelesen werden.

Ich möchte diese Funktion, weil ich heute eine Beispielimplementierung meiner Bibliothek mit Express schreibe, aber keiner meiner Codes direkt von Express abhängt. Ich möchte nicht, dass etwas installiert wird oder von Express abhängt, aber ich möchte es in meinem aktuellen Verzeichnis installieren.

Genau wie bei @ brendan-hurley @suyanhanx habe ich Abhängigkeiten, die ich in CI und nicht lokal installieren möchte.
Ich möchte meine lokalen Abhängigkeiten auf ein Minimum beschränken, damit wir nicht node_modules aufblähen müssen und uns Zeit und Platz für jeden Entwickler kosten, der an dem Projekt arbeitet.

Pakete, die in CI benötigt werden, aber nicht lokal:

  • CI-spezifische Tools: Semantic Release, Greenkeeper-Lockfile
  • Tools zur Berichterstattung über die Abdeckung: Codacy-Abdeckung, Overalls
  • Testberichterstellungstool für CI: jest-junit usw.

Hier ist, warum wir diese Funktion benötigen:

Wenn Sie yarn link , werden die Abhängigkeiten des Pakets nicht miteinander verknüpft, sodass Sie sie installieren müssen
Das verknüpfte Ziel - das Hinzufügen dieser externen Abhängigkeiten zu package.json macht es einfach so unpraktisch.

Entweder muss yarn link Abhängigkeiten hinzufügen oder eine Möglichkeit bieten, das Ziel package.json auszuschließen

Ich habe einen ziemlich esoterischen Anwendungsfall, aber das wäre hilfreich für mich. Ich verstehe voll und ganz, warum es wichtig ist, dass yarn.lock und package.json die Quelle der Wahrheit sind, und dass meine Änderungen bei nachfolgenden yarn gelöscht werden, wenn ich einen Befehl --no-save yarn Befehle.

Das heißt, ich wünschte, yarn würde mir vertrauen, dass ich weiß, was ich tue, und mir erlauben, die --no-save -Fahne zu übergeben. Wenn ich auf einen der Problemfälle stoße, weiß ich genau, was schief gelaufen ist und dass ich nur mich selbst beschuldigen muss. :Lächeln:

Mein Anwendungsfall?
Ich verwende eine 64-Bit-Win-Maschine.
Prod-Maschine ist 32-Bit.

Die Node-Sass-Abhängigkeit, die wir haben, unterstützt nur 32-Bit, es sei denn, wir aktualisieren das Paket.

Die Abhängigkeit in package.json oder yarn.lock wird nicht geändert, um eine Entwicklungsmaschine zu unterstützen.
Sie möchten also lokal den neuesten Node-Sass installieren, um 64-Bit zu unterstützen, haben jedoch keine Auswirkungen auf package.json und yarn.lock

Ich möchte @types/* Pakete in Nicht-TypeScript-Projekten installieren, ohne package.json / yarn.lock für eine bessere automatische Vervollständigung in VSCode zu beeinträchtigen.

Ich benutze Lerna mit Garnarbeitsbereich.
Die Typdefinition von Antd ist aufgrund der Aktualisierung von @ types / [email protected] unterbrochen .
Antd wird das am Wochenende beheben.
Aber jetzt muss ich das Garn zwingen, eine feste Version von @ types / [email protected] manuell in

Das Standardverhalten beim Speichern in package.json beizubehalten ist richtig, aber es gibt echte Fälle, in denen Entwickler das Modul installieren müssen, ohne die package.json zu beeinflussen. Besonders wenn es in einigen Paketen zu unerwarteten Änderungen kommt.

Das implizite Aktualisieren des Pakets und das implizite Speichern in package.json führen zu Konflikten.

Hier ist ein weiterer Anwendungsfall. Ich unterhalte eine React-Bibliothek. Bevor ich eine neue Version veröffentliche, möchte ich meine Tests für mehrere Versionen von react und react-dom ausführen, um zu überprüfen, ob meine Änderungen vorwärts und rückwärts ( @next ) kompatibel sind. Ich habe dies mit dem folgenden Setup gemacht, aber jetzt möchte ich die Arbeitsbereiche von Yarn verwenden, damit ich zu Yarn migrieren muss.

"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"

Ich kann dieses Skript nicht dazu bringen, meine package.json ändern, da dadurch mein Veröffentlichungsbefehl ( pack publish ) aufgrund nicht bereitgestellter Änderungen fehlschlägt.

Ich möchte meiner CI-Pipeline zu Testzwecken zusätzliche Pakete hinzufügen, ohne die Datei package.json zu berühren (möglicherweise ein schreibgeschützter Dateimount).
Diese sind nicht Teil der Entwicklungskomponenten.
Während der Entwicklung und des Testens auf den Entwicklungsmaschinen dürfen sie nicht installiert werden, und während des Aufbaus und der Herstellung dürfen sie nicht installiert werden. Sie sind nur während der Tests auf dem CI-Server erforderlich und akzeptabel.

Dies funktioniert nur mit npm, aber Garn sollte in der Lage sein, die Abhängigkeit von npm zu beseitigen.
Dies könnte uns sehr gut dazu bringen, nur npm anstelle von nur Garn zu verwenden.

Außerdem bricht es nur das Versprechen, dass Garn npm vollständig ersetzen kann, weil es einfach nicht das kann, was npm kann.

Ja, diese Funktion muss unbedingt hinter einem Flag versteckt werden, da dies kein normaler Anwendungsfall, sondern ein Edge-Anwendungsfall sein sollte.

Machst du Witze ? 3 Jahre, um einen einfachen Schalter hinzuzufügen?

Ein weiterer Anwendungsfall: Wir verwenden ein npm-Paket ( git-hoooks ) für Pre-Commit-Prüfungen. Nicht jeder im Team hat einen Knoten installiert, daher würde die Aufnahme in package.json die Commits für einige Personen unterbrechen. Ich versuche also, npm-Skripte zu erstellen, um Hooks vorübergehend zu aktivieren / deaktivieren, indem ich Git-Hooks installiere / entferne. Sehr enttäuscht, diese scheinbar einfache und leichte Aufgabe herauszufinden, ist mit Garn praktisch unmöglich zu erreichen.

Wenn die Sorge ist, dass yarn.lock keine Quelle der Wahrheit mehr für den Inhalt von node_modules ist, was ist daran so schlimm? Könnten vorhandene Funktionen nicht einfach die Existenz der nicht verfolgten Abhängigkeiten ignorieren? Garn ist ein großartiges Werkzeug, und die Betreuer haben der JS-Community einen großartigen Dienst erwiesen, aber sie müssen diese Entscheidung überdenken.

Machst du Witze ? 3 Jahre, um einen einfachen Schalter hinzuzufügen?

@spanasik und @Ryuurock : Bitte seien Sie höflich, wenn Sie über hochwertige Software

Dies hat nicht "3 Jahre" gedauert, da die Implementierung des Switches zu kompliziert ist - weil die Betreuer nicht davon überzeugt sind, dass dies ein Nettogewinn für die Benutzer ist. Wenn Sie damit nicht einverstanden sind, machen Sie ein Argument für die Funktion.

@ NickHeiner hier sind 10 Bildschirme mit Argumenten. Und die Hauptsache, die die Frustration antreibt, ist nicht, dass die Betreuer nicht überzeugt sind, sondern dass sie sie ignorieren und nicht auf Argumente antworten, wenn die Leute "nicht damit einverstanden sind, ein Argument für die Funktion vorbringen". Und wenn Leute frustriert sind, hinterlassen sie natürlich unangenehme Kommentare. Bitte beschuldigen Sie nicht die Benutzer.

Ich stimme zu, dass es besser wäre, wenn die Betreuer die Diskussion hier ansprechen würden. Es gibt eindeutig Interesse von einer breiten Palette von Menschen über mehrere Jahre. Vielleicht ist mein Vorschlag, dass @spanasik und @Ryuurock nur "argumentieren" sollten, unvernünftig, weil er wahrscheinlich wie alles andere hier ignoriert würde.

Und wenn Leute frustriert sind, hinterlassen sie natürlich unangenehme Kommentare. Bitte beschuldigen Sie nicht die Benutzer.

Ich stimme dir nicht zu. Diese Unhöflichkeit ist immer noch kein nützlicher Schritt nach vorne und auch kein akzeptables Verhalten bei Erwachsenen. Unhöflich zu sein ist eine großartige Möglichkeit, um die Betreuer zu rechtfertigen, die dies weiter ignorieren: "Der Faden ist nur Trolle".

Konstruktive Wege, um voranzukommen:

  1. Machen Sie den Betreuer auf anderen Kanälen auf diesen Thread aufmerksam (vielleicht haben sie ihn ignoriert) und bitten Sie ihn, die Argumente hier zumindest anzuerkennen, auch wenn sie nicht einverstanden sind.
  2. Gabel / ersetzen Sie das Garn und steuern Sie das Projekt so, dass die Menschen zufriedener sind.

Praktischer Trick ist yarn add --dev pkg && yarn remove pkg . Es macht das Gleiche. Die Sperrdatei bleibt so, wie sie vorher war, so unberührt.

Getestet - funktioniert nicht.

Mein Anwendungsfall ist der folgende:
Einige Pakete verfügen über optionale Add-Ins, die mit 'require' geladen sind. Ich möchte diese Add-Ins nicht zum Abschnitt devDependencies hinzufügen, also führe ich ein 'Garn-Add-In' aus und entferne es manuell aus der Datei package.json. In meiner Cloud-CI-Pipeline verwende ich 'npm i' und füge sie hinzu (zum Testen). In meiner lokalen Pipeline möchte ich npm nicht verwenden, da dadurch eine zusätzliche Sperrdatei erstellt wird. Meine beste Option ist jetzt, npm zu verwenden und dann ihre Sperrdatei zu löschen (um die erscheinende zweite Version der Wahrheit zu entfernen).

Nachdem ich alles gelesen habe, ist meine Frage an die Betreuer:

  • Warum bist du so inkonsistent?
  • Warum nicht diese Philosophie in jeder Funktion umsetzen?

    • Das heißt: Entscheiden Sie, wie die Dinge für uns alle getan werden sollen, und entfernen Sie alle anderen Optionen aus allen Funktionen. Bleib auf Kurs! Bleib dir selbst treu!

Die unbestreitbare Tatsache ist, dass jede gute Software Konfigurationseinstellungen hat, da der Benutzer mit guter Software auswählen kann, was für seine Situation am besten ist . Und die Datei 'package.json' immer zu berühren, ist eine gute Praxis - aber es gibt Randfälle, in denen 'Garn' aufgrund dieser Philosophie einfach nicht der Aufgabe gewachsen ist.

Ich mag Garn sehr, weil es einfach und schnell ist . Es ist wirklich bedauerlich, dass die Betreuer einen Kampf führen, den sie mit Sicherheit verlieren werden - weil die Community gezwungen ist, auf langsame, zuverlässige npm zurückzugreifen, damit die Dinge funktionieren.

Lassen Sie uns die Temperatur etwas senken. Niemand muss sich von a angewidert fühlen
Software, die sie kostenlos nutzen dürfen.

Am Mittwoch, 15. Januar 2020 um 23:17 Uhr Hajime Yamasaki Vukelic <
[email protected]> schrieb:

Ich bin angewidert, dass Garn mich auf eine bestimmte Weise arbeiten lässt. ich mache gerne
Entscheide selbst, und ich mag es nicht, wenn meine Werkzeuge mir sagen, wie ich
sollte funktionieren, Beleidigung meiner Intelligenz als das geringste Problem, und
nicht in der Lage zu sein, Dinge zu erledigen, ist bei weitem das Größte.

An perfekte Regeln zu glauben und dass es niemals eine Gelegenheit dazu geben würde
sie zu brechen ist naiv. Es gibt einen Unterschied zwischen "Best Practices" und
"do-or-die". Wie Oliver Wendell Holmes Sr. es ausdrückt:

Der junge Mann kennt die Regeln, aber der alte Mann kennt die Ausnahmen.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/1743?
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA
.

Machen Sie Ihren eigenen Paketmanager, niemand bringt Sie dazu, etwas zu tun.

Überhaupt nicht böse, nur auf den Fehler in Ihrer Logik hinweisen:

Garn bringt mich dazu, auf eine bestimmte Weise zu arbeiten.

Garn bringt dich nicht dazu, irgendetwas zu tun, sie haben ein Werkzeug (kostenlos) gemacht und es funktioniert auf eine bestimmte Art und Weise. Wenn es dir nicht gefällt, benutze etwas anderes.

@ Foxbunny Ich schätze es, dass Sie Ihren Ekel klarstellen. :) :)

Selbst wenn Sie glauben, dass es vernünftig ist und sich in diesem Fall nur angewidert fühlt, denke ich nicht, dass Sprache eine höfliche Art ist, mit den Leuten zu sprechen, die dieses frei verfügbare Tool für Sie entwickelt haben. Sie können konstruktives Feedback geben und trotzdem respektvoll sein.

@whitecolor das Team hat einen Punkt. Diese Option - Speichern ist dumm. Garn garantiert das Gleichgewicht zwischen node_modules, package.json und der Sperrdatei und das ist großartig. Das ist sicherer ... das npm - Speichern ist gefährlich. Es hat mich viele Male im Stich gelassen

Bitte hör auf

Oder wie wäre es, wenn jeder einfach das Tool verwendet, das so funktioniert, wie er es für besser hält, und sich beruhigt.

Mein Anwendungsfall ist

Ich möchte die Unterabhängigkeit unserer App aktualisieren
Ich verknüpfe diese Abhängigkeit mit yarn link
Ich benutze dann einen verknüpften in unserer App
Ich füge einige Abhängigkeiten in unserer Bibliothek hinzu
Die hinzugefügte lib-Abhängigkeit wird nach yarn install (wtf no.1) nicht in der Haupt-App installiert.
Dann denke ich, ok, lass es uns einfach schnell hinzufügen, ohne es in der App zu speichern, damit ich überprüfen kann, ob etwas funktioniert, bevor ich ein Update für unsere Bibliothek veröffentliche
Aber nein.

Vielen Dank

Es tut uns leid, dass die Community von den Autoren ignoriert wurde.

Als Open-Source-Freiwilliger muss man eine kohärente Philosophie haben oder die
Projekt wird in einen Schlammballen zerfallen. Das heißt manchmal erzählen
Leute "nein". Wenn Sie nicht einverstanden sind, können Sie gerne Ihr eigenes Paket zusammenstellen
Manager, genau wie Garn npm ersetzt.

Am Dienstag, 3. März 2020 um 03:53 Uhr Artur Kwiatkowski [email protected]
schrieb:

Es tut uns leid, dass die Community von den Autoren ignoriert wurde.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/1743?
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA
.

Ich verwende Lerna und möchte wirklich nur Lerna in einem meiner CI-Schritte für die Veröffentlichungsphase installieren, da das Projekt bereits in einem vorherigen Schritt erstellt und Artefakte übertragen wurden. Ist das ein gültiges Szenario?

^ Mein ursprünglicher Kommentar - Ich weiß ehrlich gesagt nicht, warum ich das jemals brauchen würde, und ich wusste nicht, dass dieser Thread so schrecklich explodieren würde - aber es ist amüsant, Jahre später E-Mails darüber zu sehen.

Ich bin geneigt, den Betreuern hier zuzustimmen:

  1. Ich bin von meiner eigenen Argumentation nicht überzeugt. Ich denke, die Betreuer waren höflich, indem sie es nicht als dummes Argument bezeichneten.
  2. Selbst wenn jemand eine PR auslöst, würde dies bedeuten, dass die fortlaufende Wartung der Funktion die weitere Belastung für die Betreuer darstellt und sie daran hindert, das Kernprodukt zu warten.
  3. Diese Art von Merkmal würde von unscheinbaren Neulingen und / oder auf andere Weise relativ ungelernten Garnkonsumenten missbraucht, was Punkt 2 weiter aufrechterhält.

In jedem Fall gibt es wahrscheinlich eine bessere, architektonisch fundiertere Möglichkeit, die Notwendigkeit dieser Funktion zu mindern.

Ich habe yarn-add-no-save , um diese Funktionalität zu erreichen. Es kann lokal für Ihr Projekt oder global installiert werden:

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

Nach der Installation können Sie einfach Folgendes ausführen:

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

Mein Anwendungsfall besteht darin, Module zu testen, die peerDependencies deklarieren, damit das Tool einige Optionen hat, um sie automatisch zu installieren und alle ausgeführten Optionen anzuzeigen:

$yarn add-no-save --help

HINWEIS: Ich bin mir bewusst, dass das Speichern eines Pakets zum Installieren von Paketen ohne Speichern ironisch ist und im Grunde genommen den Zweck zunichte macht. Dies ist jedoch das Beste, was ich mir einfallen lassen kann, und es entspricht meinen Anforderungen.

Dies ist sehr hilfreich, insbesondere die Unterstützung von PeerDeps. Vielen Dank.

Für diese Funktion gibt es mehrere gute Argumente. Es ist nicht so, als würde man es als Standard verwenden. Die Leute fordern, dass es hinter einer klaren Flagge steht, die nur von Menschen verwendet wird, die es brauchen. Derzeit muss ich wie andere Tests während des CI einige Tests mit anderen Bibliotheksversionen durchführen, die ich nicht speichern möchte . Ich kann nicht verstehen, was hier so schwer zu verstehen ist.

Ich muss yarn install xxx dann yarn remove xxx .

Ich bin mir nicht sicher, ob dieser Anwendungsfall jemals besprochen wurde. Lassen Sie mich versuchen, meine Situation zu erklären - ich habe eine Reihe von Paketen, die in einem Repo voneinander abhängig sind. Sie alle verwenden dieselben externen Abhängigkeiten mit einem gemeinsamen Paket bei Root-Servicing-Unterprojekten darunter. Jedes lokale Paket muss in der Reihenfolge erstellt werden, in der das nächste verwendet werden soll. Ich versuche dafür Garnarbeitsplätze zu verwenden. Zu Beginn habe ich keine lokalen Pakete in meiner root package.json definiert. Nach einem vollständigen Zyklus des Erstellens aller Komponenten habe ich ein vollständig aktualisiertes root package.json mit diesen lokalen Abhängigkeiten. Wenn dieses Update auf CI basiert, werden alle hinzugefügten lokalen Pakete aufgrund von Nichtverfügbarkeit fehlschlagen. Wir müssen diese neu hinzugefügten Einträge entfernen, damit es in CI funktioniert.

Ich muss yarn install xxx dann yarn remove xxx .

das Gleiche

Hier ist ein Anwendungsfall, um dies tun zu können:

Wir erstellen ein Tool mit einem modularen Ökosystem für "Appliances" innerhalb des Tools. Es ist geplant, eine lokale Instanz mit diesen Appliances einzurichten und diese über die Konfiguration dynamisch zu aktivieren. Die Appliances werden auf npm veröffentlicht (und können außerhalb unseres Frameworks aufgerufen werden, wenn jemand dies wünscht).

Das Vanille-Projekt hängt NICHT von diesen Paketen ab, daher wäre das Speichern auf package.json unangemessen. Die Konfiguration einer bestimmten Instanz erfordert möglicherweise die lokale Installation eines der Pakete.

Das Fehlen dieser Funktion scheint eine begrenzende Entscheidung für unser Projekt zu sein, obwohl wir weiterhin nach alternativen Ansätzen suchen werden.

Bevor ich hier die Antwort "Betreuer" las, dachte ich, ich sei die sturste Person, die es je gab.

Fast 4 Jahre ... 🤦

"Sturheit" ist nicht dasselbe wie "eine Designvision zu haben und nicht alles umzusetzen, was jemand verlangt".

"Sturheit" ist nicht dasselbe wie "eine Designvision zu haben und nicht alles umzusetzen, was jemand verlangt".

Die Designvision beschreibt einen glücklichen Weg, und Fluchtluken, wie sie hier angefordert werden, tragen zur Nützlichkeit für die breitere Gemeinschaft bei.

Warum nicht einfach einen Abschnitt zur Sperrdatei hinzufügen, der "Freiform" -Installationen und inkrementelle Schnappschüsse des Status Quo (in node_modules ) verfolgt, um diese sicher umkehrbar zu machen? Oder legen Sie Abhängigkeiten in einen Ordner, der von node_modules getrennt ist, und verwenden Sie node_modules, um die Links für das Paket offen zu halten, damit Yarn die Inhalte selbst verwalten kann und sich keine Sorgen über das Überschreiben und Brechen unsichtbarer Installationen machen muss.

Git hat dieses Problem Jahrzehnte vor Ihnen gelöst. Lass dir einfach etwas einfallen! Das ist es, was Design bedeutet - Einschränkungen zu umgehen, anstatt sie zu bekämpfen (oder ihnen nachzugeben).

Die Tunnelvision an beiden Enden ist hier aus Unwissenheit, Überdenken und unnötiger Polarisierung entstanden. Es gibt keine Kampfkünste oder Philosophie oder Revolution oder Politik; Es gibt nur ein Werkzeug, eine Menge Code und eine Aufgabe, die erledigt werden muss. Wenn das Tool nicht dazu beitragen kann, die Aufgabe zu erledigen, ist es kein Tool für dieses bestimmte Szenario. Und damit ein Werkzeug, das angeblich ein Allzweckwerkzeug ist, das vollständig ausgetauscht werden kann, wie es Garn ist, werden hier so viele gängige Szenarien vernachlässigt, dass es einfach sein eigenes Grab gräbt.

Ich habe das Gefühl, dass alle einen schmalen Hügel hinauf gegeneinander drücken, wenn wir es einfach umgehen könnten.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen