I'm a beginner in Symfony and I want to know what the differences between these two commands for creating a new project in Symfony.
using website-skeleton :
composer create-project symfony/website-skeleton first-project
using framework-standard-edition :
composer create-project symfony/framework-standard-edition first-project
the composer create-project command looks up the entry on packagist that correlates to the second parameter.
So symfony/website-skeleton points to: https://packagist.org/packages/symfony/website-skeleton while symfony/framework-standard-edition points to: https://packagist.org/packages/symfony/framework-standard-edition which in turn point to their respective repositories on github, which may have different names (as is the case with the framework-standard-edition one)
Those pages contain the version numbers that are being installed. The website-skeleton uses symfony/flex (which adds its own definition to the composer.json in the flex-require section which is not shown on packagist, since it's non-standard stuff), which is not quite informative.
The website-skeleton is the bootstrap for a website on the current version of symfony (which may change in the future, so it may reference a static version at some point in the future or may restrict the version number in some way), which should be symfony 5 right now.
The framework-standard-edition is the bootstrap for a website on the old 3.4.x version of symfony, which probably won't change, since it's already restricted on the version number.
If you're starting on a new project with no restriction to an old php version, you should prefer the website-skeleton.
Related
I have setup my environment as follows: Wamp 3 with PHP7.1.33 version, composer 2 and the Symfony binary.
But when I try to run symfony new my_project_name --version=4.4 --full I get this error:
Creating a "symfony/website-skeleton" project at "./my_project_name"
Your version of PHP, 5.4.12, is affected by CVE-2013-6420 and cannot safely perform certificate validation, we strongly suggest you upgrade.
[InvalidArgumentException]
Could not find package symfony/website-skeleton with version 4.4.* in a version installable using your PHP version,
PHP extensions and Composer version.
As mentionned in the error, PHP 5.4.12 is used, but when I run php --version I get 7.1.33 version.
I haven't used either WAMP or the Symfony binary, but on the documentation it says:
If you have multiple PHP versions installed on your computer, you can tell Symfony which one to use creating a file called .php-version at the project root directory
If you have multiple PHP versions installed, apparently the tool attempts to find them and list them if you use the symfony local:php:list command. No idea how it works or how reliable it is, but should tell you if it's able to detect your PHP 7 runtime.
More importantly, despite the poor advice on Symfony part, you do not really need to use the symfony binary to create a project. The binary simply calls composer, so why not call composer directly? That way you can be sure you are using the PHP and Composer's versions you want and expect, instead of relying on an intermediary.
Just do:
composer create-project symfony/website-skeleton your-project-name ^4.4
(this is what you get by using the --full flag, if you do not use it you simply install symfony/skeleton, which includes less components out of the box).
As an aside, naming the binary symfony was a really poor choice on Symfony's part, as it makes it almost impossible to search for issues related to the tool and not the framework. Or to suggest to use the binary instead of using composer directly, adding a layer of opacity for many users.
I'm currently experimenting with the Satis. I would like to be able to get the exact version of my private packages somewhere, so everything that is normally in the composer.lock. I always commit the composer.lock via Git.
But if I understand that correctly, the Satis in its packages.json always only includes the require parts, i.e. the sections from my composer.json and thus of course only version ranges.
Is there a way to configure the Satis so that the composer.locks are also stored or how do I get the exact "snapshot" of my packages?
+++ Example +++
Ok, I try to explain a bit more.
Let's say I have a package my/package. Here I add several files, including a composer.json, in which I define that symfony/console should be installed in a version greater than or equal to 4. Now I do a "composer install" and Symfony is installed in version 4.4. I commit all files, including composer.lock and create a release 1.0.
Now I'm going to the Satis. Here I add my/package and the corresponding repository URL for my/package to satis.json and update it. The Satis checks out my package correctly and in packages.json or more precisely the all*.json my package is listed with version 1.0. So far everything is fine.
But if I now take a look at the metadata that Satis stores for my package in all*.json, I see here practically my specified requirements, i.e. that symfony/console should be installed in a version greater than or equal to 4. So Satis takes a snapshot of the composer.json and apparently ignores the composer.lock. So I have no chance to see that my release 1.0 works with the exact version 4.4 of Symfony, while for example a release 1.1 works with symfony/console 4.5. But this information is interesting for me.
When installing a package, Composer recalculates all dependencies on the fly. This is based on the composer.json of your application and the composer.json files of all dependencies.
A composer.lock should not be part of any package, and it is not taken into account when a package is installed.
So, I've now built a workaround. The whole thing is not quite perfect, since the runtime for large repositories is relatively long, which is why I have to run it as a cron once a day. But it works fine.
I have created a new Satis console command.
This command uses the PackageSelection class to determine all existing packages.
I iterate over the package list and look for the paths and names to the dist files.
I extract the ZIP files in memory and look for the composer.lock. If there is one, I parse it and read the exact version numbers of the dependent packages.
I summarize the information in a separate JSON file and store it in parallel to packages.json under htdocs. From there I can call it up and integrate it into my own application or process it further.
Comparing to other package managers like npm, I find that composer has a strange behaviour when updating packages related to a given project.
According also to the documentation, update and upgrade options
Upgrades your dependencies to the latest version according to composer.json, and updates the composer.lock file.
And indeed, composer.lock is correctly updated with new packages version numbers. But composer.json instead is not modified, and lists packages with their old, outdated version numbers.
Why does this happen? Am I doing something wrong, or this is indeed how this is supposed to work? And if this is the case, what is the reasoning behind having one of thw two files up-to-date while the other is not?
That's the normal behavior.
Composer update looks for updates based on your composer.json file, so here it will look for 4.2 and above (^4.2)
If you want your composer.json to require 4.3 and above (^4.3), you can either modify it manually or call composer require once again.
Does composer provide a way to update the package a project was created with? i.e., if I create a new laravel project with the following
composer create-project --prefer-dist laravel/laravel blog
Composer will grab the latest version of the laravel/laravel package, unarchive it into the blog folder, and then run composer install from the blog folder.
What I want/need to know is, does composer provide a way for me to update the laravel/laravel package that was downloaded to the blog folder? I know I could run composer update inside the blog folder myself, but this will only update things listed in the compser.json's require property — it will not update the unarchived laravel/laravel in blog (or will it?)
As far as I know it's not really possible.
Imagine that you create a new as example Laravel project.
The composer create-project creates the skeleton with all initial routes in your configuration etc.
From the very very first moment you are starting to change the default routes, removing the default controllers and changing the default views, your project would be out of sync. because meanwhile laravel changes the skeleton to newer versions with some new default routes etc or event changes directory structure.
It would be really hard to merge those changes over your existing application.
A better solution would be to follow the "Upgrade guides" (laravel: https://laravel.com/docs/5.4/upgrade) and then just commit those changes to your own project.
If you want to upgrade to a new laravel version, you can always follow the upgrade guide for your specific version:
Laravel 5.8 to 6.0
Laravel 5.7 to 5.8
Laravel 5.6 to 5.7
Laravel 5.5 to 5.6
If you are more than one version behind, you need to apply the previous upgrade guide. So if you are on 5.6 and want to upgrade to 5.8, you need to follow the guide for 5.6 to 5.7 and then from 5.7 to 5.8.
The guides are pretty helpful: they tell you which package must be updated to what version and inform you about deprecated methods which will be removed in the upcoming versions.
Another method which you can use to upgrade to new minor versions is to just look at the differences from one laravel release to the next. That way, you can see what exactly has changed and which files are new (configuration files for example which you can copy and paste into your project as the default composer create-project command would do).
As for the current version, you can see the commits since last release here: v5.8.30 to 5.8
Directly under the headline for a release, there is a small link labelled "36 commits to 5.8 since this release" which will take you to the link above, just for the latest version.
That's not the goal of composer, that just manage your packages.
You should see composer create-project just as a shortcut of git clone + composer install. If you need to deploy your application you've multiple options, from a simple git pull, to more advanced deployment tools like Capistrano. But composer isn't one of these tools.
I just needed to do this, and I couldn't find anything simpler than a git clone and a git pull (as #Federkun). Maybe an alternative would be to publish a phar file for the project and download that?
I can see db-ping does this. It's based on joomla/using phar. Here is the main file for building, inspired from joomla's file.
I've been developing a lot of packages for composer recently, as our company is moving to composer for package management, but I'm running into issues with how to handle versions.
I've been using the git workflow, with tagged releases, but this means I can't go back to a previous major or minor release and make a patch release for it. I also have been running into issues with understanding how tagged development/beta/RC releases work with composer.
I've seen other projects use branch aliases, and I think it might solve these issues for me, but after reading the composer docs on them I still don't feel like I understand how to practically use them.
Does anyone with more experience using composer have tips/tricks on how best to version a git package repository?
1. Source Control of Composer project
I normally ignore the vendor directory using .gitignore. Indeed, this is so common that .gitignore file comes with most PHP framework would have already included the vendor directory.
Upon release, some of the steps will be:
checkout or clone from release branch/tag,
update composer ( self update )
composer install ( install all dependencies into the vendor directory )
2. Composer versoining/stability/alias confusion
Yes this is confusing, I think the most confusing part is where versions come from, and it is not easy found in the online docs. Versions come from source control's branches and tags
a Tag name is the exact version name. if you have a tag called 'xx', you can reference it in the package.json file as 'xx'. if your tag follows the semantic naming convention (e.g. 1.0.1 or v1.0.1), you can refer to it using semantic syntax like ~1.0.*.
tags are 'stable' UNLESS their semantic names contains somethings like 'RC1', 'RC2', 'alpha' etc. (e.g. 1.0.1-rc1, 1.0.1-alpha) In those cases they can be referenced by 1.0.1#RC or 1.0.1#alpha.
branches are not 'stable' by default, numbered branch will be treated as development version. e.g. branch 2.0 will be referenced as 2.0.x-dev (note the extra .x ); Non-numbered branch name will be referenced with be prefixed with 'dev-'. i.e. 'master' branch becomes dev-master and 'testing' branch becomes dev-testing.
Branch alias is used, for example, when you want to treat the master branch as 2.0.x#dev. You might want to use the dev-master branch of package ABC but it happens that one of the packages you used in your project depends on the 2.0 branch of package ABC. As you can only use one version of package ABC in your project, you basically ask all other packages to use the dev-master when they want to use the 2.0.x#dev branch
Other issues like minimum-stability and nested dependencies are clear in the online docs and I am not repeating them here.