Composer package root path
Sziasztok!
Egy egyszerű dolgot szeretnék megcsinálni, és ehhez szükségem lenne egy composer package-re.
A lényeg: egy mappában összegyűjtve szeretném tárolni az általános php/laravel/html projektekhez a szükséges dolgokat, pl: gulp file example, sass alapok, appconfig js, stb. Sikerült is csinálnom egy
teszt package-et (éljen-éljen!! ), de nem sikerül belőnöm azt, hogy a telepítési mappa ne a vendorba menjen, hanem a project root részén hozzon létre egy mappát.
a composer.json jelenleg:Elvileg az extra kulcsban kéne beállítani, de még nem jöttem rá, hogy hogyan, hiába nézem a doksit, nem igazán esik le...
Ha valaki csinált már ilyet, kérem segítsen a telepítési mappa belövésével.
Előre is köszönöm a segítséget!
Üdv:
Szobek
■ Egy egyszerű dolgot szeretnék megcsinálni, és ehhez szükségem lenne egy composer package-re.
A lényeg: egy mappában összegyűjtve szeretném tárolni az általános php/laravel/html projektekhez a szükséges dolgokat, pl: gulp file example, sass alapok, appconfig js, stb. Sikerült is csinálnom egy
teszt package-et (éljen-éljen!! ), de nem sikerül belőnöm azt, hogy a telepítési mappa ne a vendorba menjen, hanem a project root részén hozzon létre egy mappát.
a composer.json jelenleg:
{
"name": "szobek/front-end-dev",
"description": "It's a directory for my all laravel and other project. Included: examples (gulp.js, appconfig.js, etc), angular files, sass files with todos, bootstrap, jquery, moment js.",
"type": "project",
"license": "MIT",
"authors": [
{
"name": "szobek",
"email": "szobek##kukac##szobekweb.hu"
}
],
"minimum-stability": "dev",
"require": {
"php": ">=5.3.0",
"composer/installers": "~1.0"
},
"extra": {
"installer-paths": {
"front_end": ["vendor/package"]
}
}
}
Ha valaki csinált már ilyet, kérem segítsen a telepítési mappa belövésével.
Előre is köszönöm a segítséget!
Üdv:
Szobek
Off
Nem ennyire össszetett
Csomag
Én a Commanderben F7-tel hozok létre mappát, és F5-tel másolgatok fájlokat immáron huszonöt éve, ennél egyszerűbbet nem tudok ajánlani. Sajnos csak ennyivel tudtam segíteni.
Ezért kár volt hozzászólnod.
Kedves Gábor. Eddig én is így
Félre ne érts!
Ezek a "szoftverek" nagyon összetettek, és sosem tudhatod, a fejlesztők mit rontottak el az új verzióban. Mostanában javascript keretrendszereket vizsgálok, ha jól emlékszem, a vue.js-nél volt olyan, hogy az API tíz százalékát változtatták meg visszafele nem kompatibilis módon, vagy például a react bizonyos böngészőkön 30%-ot lassult egy verzióváltásnál.
Szóval én inkább a kézi telepítést és frissítést javaslom, úgy, hogy előbb egy saját gépen végigteszteled az új verziót.
composer verziókövető
"elasticsearch/elasticsearch": "5.0.*", szobek szerintem hasonlóan csinálja, emiatt még egyáltalán nem indokolt a "kézi" frissítés.Egyszerűen annyi, hogy amikor ki akarod próbálni a (mondjuk) 5.1.0 verziót, akkor ezt az egy sort módosítod egy json fájlban, rebuild, és már keresheted is a verzióváltás okozta hibákat. :)
Ennek a lényege abban rejlik, hogy nem tudsz kifelejteni egy (több) "alkatrészt", mint a kézi másolgatásnál.
Szobek, a helyes válasz szerintem itt van.
Köszönöm a kifejtést
Mert a példádban is
Mert a példakódban is ez
ha jól értem ez csak a típust jelöli.
Kézi
Azért ne felejtsd el:
Másrészt a példámban is ott a "*", és létezik "latest" verzió is.
Csak jeleztem, hogy ha félsz automatikusan mindig legfrissebbre váltani valamiből, akkor arra is van jobb megoldás a kézi másolgatásnál.
De te az élő fába is belekötsz. :)
Mi úgy oldottuk meg ezt a
Ezeknek része gyébként egy-egy composer.json vagy egy bower.json is, ami összeszedi a project egyéb függőségét is.
Kicsit úgy érzem, mintha két problémát szeretnél egy olyan eszközzel megoldani, ami csak az egyikre szolgál normális megoldást. Lehet a forkolást sem erre specializálták, de nálunk működik így.
Egyébként berendezkedtünk a fenti projecttípusokra, amennyire csak lehetett, egy rakat saját komponens ki van téve composer illetve bower packegbe. Rengeteg időt spórolunk a fejlesztéssel így. Természetesen a cél szentesíti az eszközt: nem mindig ezt használjuk, nem adjuk el csak azért, mert ezünk van. Ha kell, természetesen tök mást használunk.
Szia. Igen, nálam is hasonló
Értem mit szeretnél, de
1. Szeretnél vendorokat, külső függőségeket kezelni
Ezt a composer megoldja.
2. Szeretnél egyéb dolgokat kezelni - gulp file example, sass alapok, appconfig js
A fenti három pont közül (és gyanítom a stb-ben is van pár ilyen) kettő szerintem nem composer által kezelendő külső függőség, hanem egy alap, egy skeleton, egy váz, ami alkalmazás secifikussá fog válni, nem third partyként fog viselkedni,
- gulp file example: minden projectnek lesz saját igénye
- appconfig js: config, tehát alkalmazás/környezet specifikus
- sass alapok: amit ezek szerint ki lehet terjeszteni > ennek szerintem vendorban a helye
Amit te szeretnél, arra én composert nem használnék, mert ha növeled a package verzióját, és adott esetben nem fix verzióval hivatkozod be egy composer.json-be, és mondjuk felülírtad a tartalmát a project egyik igénye miatt, és futtatsz rajt egy composer updatet, akkor jogosan írja felül a composer az általad módosított fájlokat az ő saját verziójával, kvázi elvesztek a project specifikus módosításaid, amiket viszont illik verziókezelni, kvázi nem third partyként - adott esetben composerrel - használni.
Van az a pont, ahol duplikálni kell bizonyos dolgokat azért, hogy ne szivasd meg saját magad, ezért javasoltam a skeleton projectet, ahol összerakod a project vázát:
- gulp fájllal, sass alapokkal, keret index fájllal, előre legyártott könyvtárszerkezettel, config fájlokkal, default bower.json-nel, default composer.json-nel
Ezek mindegyike projectenként változhat, ezért nem tartom célszerűnek őket egy composer packagbe kitenni, mert ezek az állományok nem kiterjesztődnek, hanem módosulnak, felülírodnak.
Szia! Köszönöm a kifejtést és
De gondolkozok még kicsit, és ha jutottam valamire, közzéteszem, ha érdekel valakit egyáltalán. :)