Ankündigung

Einklappen
Keine Ankündigung bisher.

Frontend Abhängigkeiten mit composer?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Frontend Abhängigkeiten mit composer?

    Guten Abend,

    ich hab mit Frontend bisher wenig Erfahrungen gesammelt und das meiste war eher "rumgespiele".
    Nun hat mein aktuelles Projekt einige Abhängigkeiten (jquery, bootstrap, font-awesome). Da Composer schon für z.B. den Swiftmailer in Benutzung war, fand ich es naheliegend auch diese Abhängigkeiten über composer zu verwalten, hab kurz nach den Paketen gegoogelt und bin auch fündig geworden.

    Nun liegt aber mein vendor Verzeichnis außerhalb des documentroot-verzeichnisses, in dem z.B. der Swiftmailer auch nichts zu suchen hätte.

    Bin ich auf dem Holzweg und Composer ist dafür nicht geeignet? oder kann ich meinem Composer vielleicht mitteilen, dass er 2 verschiedene Ordner anlegen soll?

    Ich würde ungern eine zweite composer Instanz nutzen oder andere Paketverwaltungstools (z.B. bower kam hier beim googlen regelmäßig auf), der Einfachheit wegen.

    Wie verwaltet man (ihr ) Frontend-Abhängigkeiten (semi-)professionell?

    Liebe Grüße
    ChromOxid

  • #2
    Nun, ich würde dir trotzdem raten mal Bower anzuschauen. Dessen Spezialgebiet ist ja gerade Frontend. Und wenn man sich mal einige Projekte auf GitHub anschaut, stellt man fest, dass oft mehrere Paketmanager zum Einsatz kommen. Vor allem ist mir das bei Projekten im Umfeld von node.js aufgefallen (hier npm und Bower).

    Kommentar


    • #3
      Das sehe ich tendenziell auch so. Siehe zum Beispiel auch diese Frage: http://stackoverflow.com/questions/3...ublic/34423601

      Es ist nicht *völlig* abwegig, Composer auch zur Einbindung von derlei Frontend-Packages zu nutzen, aber es ist wahrscheinlich nicht die beste Option.

      Kommentar


      • #4
        Danke für die Antworten und auch den Link, die dort gestellte Frage trifft meine Situation wie die Faust aufs Auge.

        Nach nun schon einiger Recherche bin ich noch auf einige interessante Tools gestoßen, z.B. https://webpack.js.org/guides/installation/
        Einerseits stelle ich nun Überlegungen an, ob das nicht alles ein bisschen zuviel des Guten für mein Projekt ist und andererseits "ärgere" ich mich, das nahezu alles NodeJs bzw. npm benötigt. Ich finde es doch etwas seltsam sich eine neue Abhängigkeit ins Haus zu holen, um dann einen weiteren Paket-Manager zu installieren mit dem ich Abhängigkeiten verwalte.

        Inzwischen bin ich aus oben genannten Gründen dabei das composer asset plugin mit nachfolgender Konfiguration der Ordner auszuprobieren. - Das scheint mir, für die eher geringe Komplexität des Projektes, der für mich beste Weg zu sein.

        Kommentar


        • #5
          Gerade diesen aktuellen Artikel gefunden: https://www.sitepoint.com/game-devel...ible-are-they/

          Er hat nicht unbedingt einen ganz allgemeinen Fokus, aber ist vielleicht mal interessant zu lesen, weil der Autor recht ausführlich seinen Setup-Prozess für Dependencies in Back- und Frontend beschreibt.

          Grundsätzlich würde ich vielleicht noch den Tipp geben, es mit externen Tools und Package-Managern und dergleichen nicht zu übertreiben, die Setups und Workflows also nicht zu komplex zu machen, andererseits aber auch keine Angst davor zu haben, die gebräuchlichen Tools zu nutzen, auch wenn es erst mal etwas anstrengend sein kann, bis man alles korrekt laufen hat (gerade wahrscheinlich unter Windows). Das ist gut, weil man neue Sachen lernt und weil man sozusagen mehr state-of-the-art bleibt. Das ist meines Erachtens mittelfristig immer von Vorteil, weil man sich nicht „künstlich“ in dem einschließt, was man kennt, und sich damit gewissermaßen ein wenig von bestimmten Ansätzen und Vorgehensweisen abschottet. Außerdem weiß man auch dann, wenn man sich letztlich nicht für eine bestimmte Vorgehensweise entscheidet, immerhin fürs nächste Mal diese Vorgehensweise besser einzuschätzen.

          Kommentar


          • #6
            Meine Empfehlung lautet: nutze npm, denn das hat sich mittlerweile sehr stark etabliert und bietet in Kombination mit einem ES6-Transpiler einige Vorteile. Bspw. kannst du jQuery sehr leicht einbinden, nachdem du es mittels `npm i jquery` installiert hast:
            PHP-Code:
            import {$} from 'jquery'
            Hierbei wird automatisch das Paket aus node_modules referenziert und dann bspw. von webpack in dein JS-Bundle gepackt; du musst also nicht mehr mit Pfaden herumhantieren. Wenn du webpack nutzt, kannst du auch mehrere Bundles erzeugen lassen, bspw. ein app-Bundle und ein vendor-Bundle. Dein JS-Code und die Abhängigkeiten (node_modules) platzierst du dabei außerhalb des Document-Roots. Die fertigen Bundles lässt du automatisch im Document-Root platzieren. Das gleiche Prinzip lässt sich auch mit SCSS anwenden. So kannst du bootstrap-sass via npm installieren und mittels import-Statement einbinde.
            [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

            Kommentar


            • #7
              Zitat von lottikarotti Beitrag anzeigen
              Meine Empfehlung lautet: nutze npm, denn das hat sich mittlerweile sehr stark etabliert und bietet in Kombination mit einem ES6-Transpiler einige Vorteile. Bspw. kannst du jQuery sehr leicht einbinden, nachdem du es mittels `npm i jquery` installiert hast:
              PHP-Code:
              import {$} from 'jquery'
              Hierbei wird automatisch das Paket aus node_modules referenziert und dann bspw. von webpack in dein JS-Bundle gepackt; du musst also nicht mehr mit Pfaden herumhantieren. Wenn du webpack nutzt, kannst du auch mehrere Bundles erzeugen lassen, bspw. ein app-Bundle und ein vendor-Bundle. Dein JS-Code und die Abhängigkeiten (node_modules) platzierst du dabei außerhalb des Document-Roots. Die fertigen Bundles lässt du automatisch im Document-Root platzieren. Das gleiche Prinzip lässt sich auch mit SCSS anwenden. So kannst du bootstrap-sass via npm installieren und mittels import-Statement einbinde.
              Ja, das ist auch meine Meinung. Npm reicht völlig aus, Du brauchst kein bower. Bower ist zu einer Zeit entstanden, wo npm noch nicht so gut war wie es jetzt ist. Und nun ist bower einfach nur noch eine Altlast, die mal vor Jahren sehr beliebt war. Besonders bei den "new Kids in the block", die Grunt, Gulp & Co. nicht verwenden möchten (weil altbewährt und immer noch gut und so...). Bower ist quasi heute noch eine Webpack Alternative.

              Allein npm wirst Du nicht verwenden können, bzw. nicht sollen wenn Du so nette Sachen wie TypeScript oder JavaScript nach ES 6 noch verwenden willst. Dann brauchst Du noch einen Loader fürs Web, der Dir automatisch die import Statement Sachen nachlädt. Und das erledigst Du nunmal entweder mit Webpack oder Browserify, oder mit Module Loaders wie AMD, RequireJS, SystemJS usw.

              Es gibt quasi keinen Weg außen vorbei an diesen Sachen, außer Du willst wirklich jede JS Datei händisch einbinden. Das ist mehr Arbeit, als sich einmal mit npm, Grunt und SystemJS außeinander zu setzen. Also als Beispiel, denn das ist mein bevorzugter Frontend Stack.


              MFG

              derwunner

              Kommentar


              • #8
                Zitat von derwunner Beitrag anzeigen
                Ja, das ist auch meine Meinung. Npm reicht völlig aus
                Das ist etwas untertrieben. npm ist verglichen zu bower ein richtiges Schwergewicht geworden. Letztlich ist bower auch nur ein node-Modul, was eine npm-Installation also voraussetzt.

                Zitat von derwunner Beitrag anzeigen
                Du brauchst kein bower. Bower ist zu einer Zeit entstanden, wo npm noch nicht so gut war wie es jetzt ist. Und nun ist bower einfach nur noch eine Altlast, die mal vor Jahren sehr beliebt war. Besonders bei den "new Kids in the block", die Grunt, Gulp & Co. nicht verwenden möchten (weil altbewährt und immer noch gut und so...). Bower ist quasi heute noch eine Webpack Alternative.
                Nope. Bower ist ein (ziemlich flachbrüstiger) Package-Manager. Im Prinzip lädt das deine Abhängigkeiten nur herunter und wirft sie in bower_components. Grunt, Gulp und Webpack sind Task-Runner, wobei webpack quasi das schweizer Taschenmesser ist und von Haus aus doch einiges mehr kann. Man kann also durchaus Bower in Kombination mit einem Task-Runner seiner Wahl verwenden - es ist nur nicht mehr zu empfehlen.
                [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                Kommentar


                • #9
                  Zitat von lottikarotti Beitrag anzeigen
                  Man kann also durchaus Bower in Kombination mit einem Task-Runner seiner Wahl verwenden - es ist nur nicht mehr zu empfehlen.
                  Gehn tut vieles, nur ob es sinnvoll ist, ist eine andere Frage...

                  Kommentar

                  Lädt...
                  X