Discussion :

[bolm2]

Bonjour à tous,

Je dois reprendre un projet réalisé avec Symfony par un prestataire extérieur dont nous n'avons plus de nouvelles.
Mais je n'y connais rien en Symfony et Composer. Par contre, j'ai l'habitude de développement en PHP sans framework.

Mon poste de travail est sous W10 et j'ai un serveur de DEV distant sous Apache/2.4.6 (CentOS). C'est sur ce serveur que je dois placer mon projet Symfony.
Ensuite, je devrai installer mon projet Symfony sur un serveur de PROD.

Mes questions:

• Est ce que je dois installer Composer sur mon poste de travail ? et dans ce cas, quid du chemin d'accès à PHP qu'il me demande lors de l'installation ?
• ou Est ce que je dois l'installer sur le serveur de DEV ? et dans ce cas est ce que vous connaitriez un tutorial pour m'aider, sachant que je préfèrerais une installation globale car je vais sans doute créer plusieurs versions de ce projet ( plusieurs dossiers à la racine HTML)
• Est ce qu'il est nécessaire d'installer Composer sur le serveur de PROD ? Si oui, est ce que vous connaitriez un tutorial pour me guider ?
• Est ce que je dois activer l'option DEVELOPPEUR lors de installation de Composer ? Qu'est ce que m'apporte cette option ?

Merci pour votre précieuse aide

Marco

[_Thomas]

Salut,

Est ce que je dois installer Composer sur mon poste de travail ? et dans ce cas, quid du chemin d'accès à PHP qu'il me demande lors de l'installation ?

Tout dépend de ce que tu comptes faire sur ton poste, si tu veux faire tourner l'application en local avant d'envoyer le code sur ton serveur de DEV/PROD, alors oui il te faudra installer Composer sur ton poste. Le chemin d'accès demandé par le wizard correspond à l'emplacement de ton php.exe local (si besoin il y a pleins de tuto pour comment installer PHP/Composer sur Windows : https://www.jeffgeerling.com/blog/20...-on-windows-10).

Est ce que je dois l'installer sur le serveur de DEV ? et dans ce cas est ce que vous connaîtriez un tutoriel pour m'aider, sachant que je préférerais une installation globale car je vais sans doute créer plusieurs versions de ce projet ( plusieurs dossiers à la racine HTML)

Je dirais que oui car on ne versionne pas les vendors et quand on clone une application on se sert justement de Composer pour installer les dépendances du projet (Composer faisant son job à partir des fichiers composer.lock et composer.json).
Pour l'installer sur le serveur, a priori tu devrais t'en sortir en appliquant la documentation : https://getcomposer.org/doc/00-intro.md#globally (si tu rencontres des difficultés n'hésite pas à revenir poser des question ici).

Est ce qu'il est nécessaire d'installer Composer sur le serveur de PROD ? Si oui, est ce que vous connaitriez un tutorial pour me guider ?

Même réponse que pour le serveur de DEV.

Est ce que je dois activer l'option DEVELOPPEUR lors de installation de Composer ? Qu'est ce que m'apporte cette option ?

Je ne sais pas à quoi sert cette option, à mon avis tu peux l'ignorer (sur Windows comme sur tes serveurs).

[bolm2]

Merci beaucoup Thomas de prendre le temps de me répondre.

Tes explications sont assez claires, malgré tout, j'ai encore 1 question (avant toutes les autres lorsque je commencerai l'installation ;-)))

D'abord, je précise que je ne veux pas faire tourner l'application en local. Je n'ai pas de serveur en local (genre Wamp), je n'ai accès qu'à un serveur distant (que j'appelle serveur de DEV).
Donc, a priori, je n'ai pas besoin d'installer Composer sur mon poste de travail, mais uniquement sur le serveur de DEV.

Mais ce que je ne comprend pas, c'est pourquoi je dois l'installer sur le serveur de PROD. Par définition, je ne vais jamais faire de développement sur ce serveur, mais juste "exécuter" le site web que j'aurai développé sur le serveur de DEV.
Je connais un peu le framework Javascript VueJS, et lorsque je déploie une application WEB (PWA), je n'ai pas besoin d'installer NPM ni NodeJS, je prend juste le dossier "public" (de mémoire), tout le reste fait partie de l'environnement de développement.
C'est sur cette comparaison que s'appuie ma question: pourquoi a t on besoin de Composer en PROD ?

Encore merci pour ton aide et les liens que tu m'indiques

Marco

[_Thomas]

En fait tout dépend de la manière dont tu vas "transférer" ton projet du serveur de DEV vers celui de PROD.

Si tu clones la totalité des fichiers (y compris le dossiers /vendor), effectivement tu devrais pouvoir te passer de Composer sur le serveur de PROD.

L'autre possibilité qui est je crois la plus courante, c'est de transférer uniquement les fichiers versionnés (donc pas le dossier /vendor par exemple) pour ensuite installer les dépendances via Composer.
L'avantage de cette dernière méthode est qu'on peut utiliser des flags spécifiques à la PROD pour améliorer les performances, n'installer que les packages "require" et pas les "require-dev" (cf. https://symfony.com/doc/current/depl...e-your-vendors), mais encore une fois rien ne t'empêcherait de faire tout ça avant sur DEV et de tout cloner vers PROD sans Composer.

Je connais assez peu le monde JS, mais je pense que yarn/npm s'utilisent de manière similaire à Composer : quand tu déploies ton application, tu ne trimbales pas les centaines/milliers de modules installés au fil du développement (le dossier node_modules) ; tu transfères uniquement le code versionné, et ensuite tu installes tes dépendances avec yarn/npm qui se basent sur package.json et package-lock.json (même si encore une fois, il reste tout à fait possible de transférer son dossier node_modules).

[armel18]

Mais ce que je ne comprend pas, c'est pourquoi je dois l'installer sur le serveur de PROD. Par définition, je ne vais jamais faire de développement sur ce serveur, mais juste "exécuter" le site web que j'aurai développé sur le serveur de DEV.
Je connais un peu le framework Javascript VueJS, et lorsque je déploie une application WEB (PWA), je n'ai pas besoin d'installer NPM ni NodeJS, je prend juste le dossier "public" (de mémoire), tout le reste fait partie de l'environnement de développement.
C'est sur cette comparaison que s'appuie ma question: pourquoi a t on besoin de Composer en PROD ?

Marco

composer en PROD tu peux t'en passer mais cela reste exceptionnel. Avec ou sans composer il faut se garder de ne pas déverser en PROD des libs propres à un environnement de DEV. Ces libs de DEV se trouvent dans la section require-dev du composer et se présentent ainsi dans le composer.json :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
  "require-dev": {
         "symfony/maker-bundle": "^1.11",
        "dama/doctrine-test-bundle": "^6.2",
        "doctrine/doctrine-fixtures-bundle": "^3.0",
        "friendsofphp/php-cs-fixer": "3.0.x-dev",
        "symfony/browser-kit": "^5.1",
        "symfony/css-selector": "^5.1",
        "symfony/debug-bundle": "^5.1",
        "symfony/phpunit-bridge": "^5.1",
        "symfony/stopwatch": "^5.1",
        "symfony/web-profiler-bundle": "^5.1"
    },

Toutes ces libs se trouvent dans le dossier vendor et ne sont pas indispensables pour la prod. Les installer en DEV alourdit inutilement ton application et ont un impact sur les performances et certaines d'entre elles peuvent être préjudiciables en terme de sécurité. Pour ne pas avoir à les installer en PROD, sur ton serveur de DEV tu peux inclure uniquement les libs nécessaires à l'application en lançant la commande suivante depuis le serveur DEV(commande généralement lancée en PROD):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
composer dumpautoload -o --no-dev

Après tu peux copier le nouveau dossier vendor pour le déverser sur la PROD. Sauf que sans passer par composer en PROD, tu risques de rencontrer des erreurs liées à l'absence d'extensions PHP requises pour faire fonctionner chaque lib et bonne chance pour déboguer ce type d'erreurs. Or en installant les libs en PROD via composer si le serveur ne dispose pas d'une extension PHP requise pour une lib donnée, composer te l'indique clairement.

Dans un projet PHP classique(avec ou sans libs), composer permet de gérer l'auto-chargement de tous les fichiers d'un projet tout en respectant les conventions PSR sur l’auto-chargement rares sont les projets qui n'utilisent pas composer de nos jours.

[bolm2]

Bonjour et merci à tous pour ces explications

C'est bien plus clair maintenant.

Ne connaissant pas du tout Symfony, j'espère que ses qualités sont à la hauteur de la complexité de sa mise en application.

Bonne journée

Marc