Remove composer.lock so that projects download latest component versions

[boesing]

Q	A
Bugfix	yes

Description

Since composer.lock is not part of the .gitignore anymore, we can change that replacement and instead, removing the composer.lock at all to prevent users from having conflicts.

The composer.lock is used by this component for CI pipeline and thus should be removed while creating a new project.

Fixes #46

[geerteltink]

Why don't we remove the composer.lock file entirely? It should always run against the latest supported versions. We can add it to .gitignore and remove it from .gitignore when the project is created.

Just another idea... why don't we use the cronjob option in actions to check daily if it builds.

[Ocramius]

Being an application, composer.lock is even more relevant, IMO

[geerteltink]

Usually I would agree, in this case I think it makes more sense to run a daily cron action then having a lockfile. By running daily tests, you know very fast that the installer broke. You could even see in the action logs why, where and when it fails. Testing against the lockfile doesn't say much in this case because the latest dependencies are always used, within the given constrains.

[boesing]

Just another idea... why don't we use the cronjob option in actions to check daily if it builds.
I would prefer having dependabot enabled so we regularly update dependencies here.

If we start as of now, I would also reduce the PHP version to exactly the latest stable version. There are always older versions which are installable with older PHP versions.
So we could change the skeleton projects to have tagged releases which will then lead to composer create-project to detect the highest possible version supported for those dependencies fulfilled by the environment which is creating the project.

Thoughts? Then I would be also fine with having a composer.lock available. But until we support multiple PHP versions, a composer.lock file have to be deleted as the composer.lock might not be compatible with multiple PHP versions.

[Ocramius]

IMO this shouldn't be done here.

We have tooling that upgrades the lock file daily, making sure that the latest & greatest works fine.

[Xerkus]

With this change when composer.lock is deleted during install? Does it solve inability to create project on php version incompatible with the lock file?

[samsonasik]

@Ocramius this skeleton update the composer.json dependency by choosing package to prefer (route, template, etc) so remove composer.lock should be fine? See issue #119

[settermjd]

I've been using PHP 8.1.25 a bit, lately, and this is consistently an issue.