Comments (17)
I think there may be a bit of misunderstanding here. The issue is only about whether or not the composer.lock
file should be included in this repo - not about whether or not projects based on Bedrock should use/include a composer.lock
file in their repos.
I think everyone agrees that including the lock file with your app/project is the way to go. I don't think this repo should add composer.lock
to its .gitignore
, but I can see the reasoning behind omitting the lock from this repo.
The lock file will be created on the first install
or create-project
, so the end result would still "include" the file either way in the fresh codebase. The difference is a smaller footprint in this repo, and potentially a better initial setup experience as the latest versions according to the defined constraints would be installed by default.
With this in mind I think "Why is composer.lock included in project?" is a valid question.
At the end of the day, I don't think it really matters all that much but maybe there's a better reason to go one way or the other.
Does dependabot require the lock file to work? Is dependabot even necessary without it?
Apart from potential integrations/inspectability I don't see a strong reason to include the lock file in this repo, but I would be interested to know if there are others.
from bedrock.
My take on this is that when using Bedrock as an upstream in git, I get conflicts on the lock file upon merging. I handle this by keeping my local version, and then updating lock after the merge is complete, which is a necessary step anyways. It would be nice to not have this merge issue, but it's a pretty common thing within our CI across multiple composer based projects, and the way to deal with it is always the same. It speak more to the composer file having stable constraints, and proper testing before it makes it way to a release.
from bedrock.
I'm in favor of leaving composer.lock in this repo, as it gives critical information on which versions of dependencies work with the project's code.
For example, in a Bedrock-based project we removed the vendor directory and composer.lock and installed, which pulled vlucas/phpdotenv version 4.1.0, in which dotenv's create() method no longer accepts a string as its argument.
By reviewing this repo's composer.lock file we were able to see on which version of dotenv the application.php file is based, allowing us to alter our code to be compatible with version dotenv v4.1.0.
from bedrock.
I'm in favor of leaving composer.lock in this repo, as it gives critical information on which versions of dependencies work with the project's code.
This is what the composer.json
's require
blocks define ๐
For example, in a Bedrock-based project we removed the vendor directory and composer.lock and installed, which pulled vlucas/phpdotenv version 4.1.0, in which dotenv's create() method no longer accepts a string as its argument.
What you're describing is a problem regarding the version constraint you have in your composer.json
. It sounds like you've modified yours as this repo has never used a constraint which could select v4 of vlucas/phpdotenv
. Currently this is ^3.6.0
which will install the latest release from 3.6.0
up to but not including 4.0
or later.
from bedrock.
We could (and maybe should) leave it out of this repo because we aren't using any wildcard dependency versions so they don't need to be "locked" down. The minor issue is we don't want to add it to .gitignore
so every contributor would have to be careful to never commit it.
from bedrock.
Going to close this for now due to the reason above. May re-visit it later.
from bedrock.
I'd like to second this. The first step of my Bedrock setup was adding the lock file to the .gitignore as is done with all of my projects.
from bedrock.
@benjibee your composer.lock
file should always be in version control for actual project repos. See https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file
from bedrock.
@swalkinshaw yes, I understand this when the given dependency version is *
or dev-master
for example. I tend to use exact versions in my composer.json
for stability as does this project, so I leave the lock file out of the repo.
Anyway, it's a minor thing, I just wanted to give my 2ยข, sorry to "bump" a closed issue!
from bedrock.
๐
from bedrock.
@QWp6t dislike removing the file or dislike that we're keeping it in Bedrock?
from bedrock.
I don't agree with removing the lock file. I agree with you that the lock serves an important function.
The idea behind the lock file is that you can include the lock file instead of including dependencies.
If you're not including the dependencies in the repo, then the lock should be included; this is especially important if the development repo doubles as your distribution channel (as is the case with bedrock).
Even if your dependencies aren't wildcards, the lock is still a good idea because it is more specific.
from bedrock.
Necrobump, sorry.
The lock provides a useful function, but committing it to the project defeats its purpose.
The .lock file's purpose is to lock my clone of the repo, after I run composer, to particular versions of dependencies. This lets me fetch the latest-and-greats versions, within the limits specified in the project's composer.json file.
If the exact version matters, it can be specified that way in composer.json. The .lock file is supposed to be created by my run of composer.
I hope this makes sense and doesn't seem contentious.
Not a huge deal, just not "proper", I don't believe, and something that jumped out at me on first look.
from bedrock.
bitwombat, I'm not following your reasoning. You're talking like once a lock file is included in the repo, the dependencies can never be changed, which is obviously not true.
If you want a set dependency, or a new one, modify the composer.json
file, run composer update
, and the lock file will be updated, and it will be all yours. So where is the issue you're experiencing?
from bedrock.
FWIW bedrock's lockfile is updated by an automated script every time WP updates
from bedrock.
I retract this and stand corrected. Composer's own docs say to commit the lock file (as @swalkinshaw said above). Though not for libraries - perhaps why I've rarely seen this.
One reasonably rated answer on Stack Exchange makes the case I did above, "but still", I now think it's correct as is.
Basically, committing the lock file is saying to your users "Use these, they're what we tested with", whereas wildcards in composer.json are saying, to devs, "We're willing to test with any of these".
from bedrock.
There's been some good discussion in here over 7 years (๐ฑ ) but I'm closing this since it's unlikely we'll change this after so long.
from bedrock.
Related Issues (20)
- .env.local failed to open stream php error when WP_ENV='development' and .env.local does not exist. HOT 5
- Installation request for roave/security-advisories (locked at dev-master, required as dev-latest) HOT 2
- Wordpress update HOT 1
- Bug: Site Editor not working on Bedrock installs HOT 4
- Bug: Openlitespeed Wordpress pretty permalinks broken HOT 1
- Bug: htaccess not blocking /app request HOT 4
- Dependency Dashboard
- Bug: wordpress-no-content ignores wordpress-install-dir HOT 1
- Feature Request: More flexible .env.* chosing HOT 5
- Bug: Multisite not working HOT 1
- Bug: WP_ENVIRONMENT_TYPE set doesn't check if constant is already defined HOT 6
- ADD: Local environment in application.php HOT 1
- Wordpress Version in composer.json is ignored HOT 1
- Upgrading WP from 6.x to 6.3.1 stops loading core block css from wp-includes HOT 3
- There is no documentation on how to add custom blocks to a theme/plugin HOT 1
- Add file to configure production environments
- Newย `WP_DEVELOPMENT_MODE`ย constant HOT 2
- Cannot override eg. DISALLOW_FILE_MODS in .env?? HOT 3
- Redis Object Cache not working on WP_ENV='production' HOT 1
- html appended to core javascript files HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bedrock.