npm und Pakete mit "-cli" und ohne "-cli"

  • Ich arbeite mich gerade in npm, package.json und Kram ein.


    Die package.json "befülle" ich derzeit mit Anweisungen der Art

    Code
    npm install -D node-sass nodemon
    npm install -D autoprefixer
    npm install -D postcss
    npm install -D clean-css-cli
    npm install -D npm-run-all

    Jetzt ist mir aufgefallen, dass auf GitHub auch package.json zu finden sind, wo statt postcss (ohne -cli) wie aus obiger Zeile resultieren würde

    ein

    Code
    "postcss-cli": "^6.1.3",

    drinnen steht (also mit "-cli").


    Kann mir jemand andeuten, was der grundlegende Unterschied zwischen solchen Paketen mit und ohne "-cli" im Zusammenhang mit npm ist?


    Danke!

  • Vergleiche ich das README beider Pakete auf GitHub

    https://github.com/postcss/postcss

    https://github.com/postcss/postcss-cli

    seh ich nicht so richtig, wozu nun ein extra -cli-Paket nötig ist und umgekehrt.


    Aber mittlerweile denke ich, dass das hier im Fall postcss der entscheidende Hinweis ist:

    Code
    npm run / CLI
    
    To use PostCSS from your command-line interface or with npm scripts there is postcss-cli.
    
    ...

    Vermute jetzt nur, dass mit "npm scripts" so was gemeint ist

    https://github.com/twbs/bootst….4.1/package.json#L41-L42


    Und hoffe nur, dass andere Pakete, wo es -cli und nicht-cli gibt, der selben Logik folgen.


    Das macht die Sache natürlich (mal wieder) zu einer Trial&Error-Orgie plus stundenlanger Recherchen bis man seine Simpel-Pimpel-Routinen beisammen hat.


    Und das -cli-Paket lädt einiges mehr als das ohne. Wart-wart-wart.


    Ich dachte halt, npm wäre der universelle, "problemlose Vermittler" zwischen Konsole und diversen Skripten.


    Bis ich's dann drauf habe, kommt vermutlich schon wieder ein "Modernisierer" um die Ecke und deklariert das Ganze als "unmodern".

    https://github.com/joomla/joom…27#issuecomment-563355347

    ;) ;) ;)

  • Und hoffe nur, dass andere Pakete, wo es -cli und nicht-cli gibt, der selben Logik folgen.

    Ich denke die Wahrscheinlich ist groß, dass dies so ist. Für die meisten steht cli ja für command line interface.

    Wenn ich mein Node Paket in verschieden Sprachen - unter anderem in Chakali - anbieten würde, würde ich mir von dir aber ungern verbieten lassen, den 639-3-Code zur Kennzeichnung anzuhängen.


    Ich dachte halt, npm wäre der universelle, "problemlose Vermittler" zwischen Konsole und diversen Skripten.

    NPM ist ein Paketverwalter für JavaScript-Umgebungen. Er übernimmt die Verwaltung der Abhängigkeiten. Über die Qualität der von dir verwendeten Skripte weiß NPM nichts.


    Was mir oft Bauchweh macht. Wenn ich ein Paket verwende, bin ich nie sicher, dass es weiter gepflegt wird. Das ist ähnlich wie bei Joomla-Erweiterungen – nicht einmal bei Joomla selbst ist die Weiterentwicklung sicher. Was im Falle von NPM aber in meinen Augen schwer wiegt: Wenn der Paketanbieter ein Paket ausliste, dann schlägt die Installation meines Paketes ebenfalls fehl, wenn ich dieses Paket verwende.


    Bis ich's dann drauf habe, kommt vermutlich schon wieder ein "Modernisierer" um die Ecke und deklariert das Ganze als "unmodern".

    Alles hat sein Gutes: So wird es nie langweilig und ohne diese menschliche Eigenschaft wohnten wir heute in Höhlen und schlügen uns mit anderen Problemen herum. Jeder entscheidet selbst, was er mitmacht. So sortiert sich das "Schlechte" hoffentlich von alleine aus.

  • würde ich mir von dir aber ungern verbieten lassen, den 639-3-Code zur Kennzeichnung anzuhängen.

    Den Satz versteh ich nicht. Im Zusammenhang mit diesem Thread.

    So wird es nie langweilig und ohne diese menschliche Eigenschaft wohnten wir heute in Höhlen und schlügen uns mit anderen Problemen herum. Jeder entscheidet selbst, was er mitmacht. So sortiert sich das "Schlechte" hoffentlich von alleine aus.

    Den Satz lass ich mal lieber unkommentiert...

    Ich denke die Wahrscheinlich ist groß, dass dies so ist. Für die meisten steht cli ja für command line interface.

    Schon klar. Aber, wenn eine Auch-Command-Line-Schnittstelle (npm) explizit die Command-Line-Pakete benötigt, andererseits aber nicht immer, ist das eben wenigsten verwirrendes, inkonsistentes Durcheinander ;) Von wem nun auch immer.

    Außerdem lassen sich die Nicht-Cli-Versionen teils ja auch an der Konsole starten.

  • Den Satz versteh ich nicht. Im Zusammenhang mit diesem Thread.

    Ich möchte damit nur sagen, dass jeder seine Node-Pakete so nennen kann, wie er mag.

    Schon klar. Aber, wenn eine Auch-Command-Line-Schnittstelle (npm) explizit die Command-Line-Pakete benötigt, andererseits aber nicht immer, ist das eben wenigsten verwirrendes, inkonsistentes Durcheinander ;) Von wem nun auch immer.


    Mit dem Durcheinander gebe ich dir recht. Aber was ist schon aufgeräumt?


    Du kannst Joomla ohne den Ordner cli verwenden. Um Dinge auf der Kommandozeile zu nutzen, brauchst du diesen Ordner aber.

    So kannst du mit npm postcss postcss installieren. Für bestimmte Funktionen auf der Kommandozeile benötigst du aber postcss-cli.


    Ich kenne PostCss nicht genau. Ich weiß nur, dass es CSS zerlegt und mithilfe von Plugins "vermeintlich besser" wieder zusammensetzt.


    Du kannst PostCss ohne

    Wart-wart-wart.

    nutzen .


    Wenn du eine bunte Kommandozeile (chalk) oder vorbereitete Hilfsmenüs(yargs) nutzen magst, dann installierst du die Cli-Variante - und wartest ...

  • Da haben sich unsere Antworten überschnitten. Letztlich gilt: Mehrere Wege führen nach Rom.

    Du kannst Joomla ohne den Ordner cli verwenden.

    Da haben wir aneinander vorbei geredet.

    1) gehts mir gar nicht um Joomla, da der ES6-lastige build-Quast sowieso unnötig kompliziert ist im Verglecih mit transparenteren, direkten Wegen, die npm möglich machen.

    2) der /cli/-Ordner ist mir schon klar. Der hat nichts mit meiner Verwirrung zu tun ;)


    Man kann sicherlich darüber streiten,

    ob eine solche Zeile im "scripts"-Block (mit "npm css-minify-main" abzuwickeln), die ich an der Konsole ähnlich basteln würde oder direkt in ein simples Shell-Script legen könnte

    https://github.com/twbs/bootst…b/v4.4.1/package.json#L38


    oder das Joomla-Prozedere, dass man sich bei ähnlicher Problemstellung durch 3 - 4 weitere ES6-Dateien hangeln muss, bevor man weiß, wie/was konfiguriert wurde


    nun "Leben in der Höhle" bedeutet ;)


    Ich kenne PostCss nicht genau.

    Ich benötige es vornehmlich für den Autoprefixer (Vendor-Prefixe-Plugin). Nachdem ich mit "clean-css" CSS minifiziert habe, nachdem ich das mit "node-sass" aus *.scss kompiliert habe.


    Und für die Variante, die ich im Unterschied zu Joomla gewählt habe, benötige ich also für diesen Teil des Vorhabens

    postcss-cli (während Joomla "nur" postcss benötigt(e) (glaub, mittlerweile wird eh nicht mehr "ge-autoprefixed") )

    clean-css-cli

    aber node-sass (ohne -cli, da das node-sass-cli mittlerweile "deprecated" ist).


    Und da CSS in meinem Test-Projekt nicht alles ist, werde ich halt weiter jedesmal vorab länger forschen müssen, um sicher zu sein, welches Paket ich zu nehmen habe.


    Und das "Wart-wart-wart" bezog sich halt auf unnötig große Pakete. npm braucht halt seine Zeit bis alle Dependencies gelöst sind. Und gerade in der Testphase geht das auf den ...