Pin behat/mink and behat/mink-selenium2-driver to use resolvable release

It works!

It should be quickly addressed because "behat/mink-selenium2-driver": "1.3.x-dev" was removed, discussion goes here.

Isn't it better to remove this dev dependency and use the 1.3.1 instead to avoid this in the future ?

@hoebekewim the proposed patch is not using a dev dependency, it is "^1.4". So it's good, right?

The Priority of this should be changed to critical as new builds cannot be installed.
This is also affecting 8.7

Agree with @simon-peacock.

The inability to install seems pretty critical to me.

Adding patch for 8.7

1.4.x-dev is definitely not the same as ^1.4. We should use the later, because that will select stable releases only. 1.4.x-dev is likely to break again if behat/mink-selenium2-driver keeps deleting their dev branches. Ostensibly they shouldn't be doing that, but we can avoid problems if we stick to stable releases. As we always should.

@greg.1.anderson

Agreed.

Thanks for updating the patch. Setting to 'needs review' to run the test.

This will need to go in 8.8.x first though.

Patch failed to apply; needs patch for 8.8.x.

@greg.1.anderson

Updating for 8.8 test

@greg.1.anderson

Correcting for 8.8

Great, looks good. Setting to "needs review" while tests run.

Correcting hash

Suggest to use "^1.4@dev" as version constrain so you don't depend on having minimum_stability = dev.

Depending on a dev release is not a good idea. 1.3.x-dev was used in the past because someone wanted to use a feature that was not available in any stable release of behat/mink-selenium2-driver. Now that there are stable releases on the ^1.4 line, we should use that. In fact, we should also use the stable release of behat/mink, the other component that we are using a dev release of, since it has a stable release now too.

Here's a patch that bumps up both behat/mink and behat/mink-selenium2-driver to use stable (non-dev) releases.

Agree with bad idea on depending on dev release. Unfortunately, you have no option here. Where do you see stable release?

docker@cli:/var/www$ composer show --all behat/mink-selenium2-driver
name     : behat/mink-selenium2-driver
descrip. : Selenium2 (WebDriver) driver for Mink framework
keywords : javascript, testing, browser, ajax, selenium, webdriver
versions : dev-master, 1.4.x-dev, v1.3.1, v1.3.0, v1.2.0, v1.1.1, v1.1.0, v1.0.6, v1.0.5, v1.0.4, v1.0.3, v1.0.2, v1.0.1, v1.0.0
type     : mink-driver
license  : MIT License (MIT) (OSI approved) https://spdx.org/licenses/MIT.html#licenseText
source   : [git] https://github.com/minkphp/MinkSelenium2Driver.git 3ab9f315e9ad63cc518ccc72910754fedd6de015
dist     : [zip] https://api.github.com/repos/minkphp/MinkSelenium2Driver/zipball/3ab9f315e9ad63cc518ccc72910754fedd6de015 3ab9f315e9ad63cc518ccc72910754fedd6de015
names    : behat/mink-selenium2-driver

autoload
psr-4
Behat\Mink\Driver\ => src/

requires
instaclick/php-webdriver ~1.1
behat/mink ~1.7@dev
php >=5.4

requires (dev)
mink/driver-testsuite dev-master
docker@cli:/var/www$

Currently, you require the dev release, as soon as 1.4.0 stable is released it is going to be used (if you update).

Updated the issue summary.

Please pay no mind to the fact that I accidentally named my interdiff ".patch" instead of ".txt".

@mmjvb: You are right. I thought that there was a 1.4.0 and a 1.4.1 release, but I must have imagined it; there are only dev releases available on the 1.4.x line. I'm going to have to update my issue summary.

I still think that ^1.4 is preferable to ^1.4@dev, because the former will use the stable releases as soon as they are available, whereas the later will continue to use the latest dev release, which is not desirable.

I think it would be good to get rid of the minimum stability: dev in the drupal/drupal composer.json file, but we should to that as follow-on work. It might be necessary to wait until Drupal 9 to make that change.

@mmjvb: OK, they attempted or began to make a 1.4.0 release in minkphp/MinkSelenium2Driver#313, but no one has made the tag yet. I think we should continue here with ^1.4, commit as soon as possible (to un-break builds, at least on drupal/core 8.8.x), and update our composer.lock with the stable 1.4.0 release when available.

^1.4@dev will use 1.4.0 stable as soon as released, obviously you need to update when having resolved to dev release. As soon as 1.4.0 is released the version constraint can become ^1.4, although ~1.4.0 would be more appropriate. Unless you would want to allow for 1.5, 1.6. That is two changes: going from dev to only stable and accepting anything > 1.4.

OK, you are right; the "prefer-stable": true, option would hold ^1.4@dev to stable releases once they are available. I think that ^1.4@dev still allows for 1.5 releases (stable). In any event, though, unless "minimum-stability": "dev", is removed (which I would like to see, but as follow-on work), ^1.4 also works, and I think that it is clearer.

My minimum_stability is not "dev", with "^1.4" the requirements can't be resolved. Only dev branch available in 1.4 !

Nothing to do with prefer_stable, composer by default takes highest version. Dev branch is considered lowest in the chain: dev,alpha,beta,rc,stable.

Ah, good point. The requirements here are not only used in drupal/drupal, but they will be copied to webflo/drupal-core-require-dev (which was the original point of this issue) and potentially used with different minimum stabilities.

Unfortunately, ^1.4 is causing errors in Drupal\Tests\views\Functional\Plugin\DisplayTest; we might need to require a specific commit on the 1.3.x branch until that issue can be resolved.

Maybe that can also be fixed upstream, hopefully before release of 1.4.0.

I didn't see anything in recent behat/mink-selenium2-driver commits that should have caused this, although the failures are related to behat, so it likely is related in a way that is not readily apparent to me. I'll try the most recent commonly-used commit (from October 2018) and see if that passes here. Everything else in that repo was added in the last week.

The failures might have been caused by updating behat/mink, which I also bumped up in this patch. Here's another version that keeps both projects pinned at the same version they were at before. Getting off the dev release can be done as a follow-on, if this works.

I'll update the issue summary if the tests pass.

+++ b/composer.json
@@ -9,9 +9,9 @@
+        "behat/mink-selenium2-driver": "dev-master#8684ee4e634db7abda9039ea53545f86fc1e105a",

I'm not sure if locking to commit is a good solution. Using commit reference is root-only composer feature.

A lot of projects are using webflo/drupal-core-require-dev to get Drupal dev dependencies. When we require that project with requirements to Mink packages with commit references, references will be ignored by the composer and we will always get dev-master.

More info here: https://getcomposer.org/doc/04-schema.md#package-links.

We had a moving target before with 1.3.x-dev alias. So nothing is changed if we just use dev-master in future too.

That is what this change is about: go with stable release (tag) instead on moving target (dev branch). Unfortunately, with 1.3 the moving target was needed due to fixes not available is stable releases. Awaiting those fixes to become available in 1.4.0 Stable. When 1.4.0 Stable arrives there is no longer a need to rely on moving target!

Due to the severity of this issue should it be pinned for now and then create a new issue to discuss the longer term approach? I suspect this is preventing and disrupting many people.

The release will need to be on 8.7 since this prevents Drupal being built via composer.

Agree with @tashaharrison80. Plus, 8.8 is not a stable release yet; whereas 8.7 cannot be updated on prod sites or built from composer - this should be the priority.

I have added a child issue for 8.7:
https://www.drupal.org/project/drupal/issues/3078904

Well darn. Since commit references are dev-only features, we have no good option other than to fix #24.

If you switch to dev-master, you will also need to fix #24, so we might as well use ^1.4, which will also give us dev-master today, but will eventually settle on a stable release, once one is available.

I did not isolate the causes of #24. Perhaps if we updated only behat/mink-selenium2-driver, we might discover that all of the failures are due to the behat/mink updates. Going half way leaves us vulnerable to being broken again when behat/mink opens the 1.8.x dev branch.

Also, the issue of webflo/drupal-core-require-dev is a separate but interesting issue. The defect here has been recorded in every single tag of that release from 8.3.0 to 8.7.6. If we fix here in drupal/drupal 8.8.x, and also do the child issue to fix 8.7.x, then the 8.7.7 release of webflo/drupal-core-require-dev will be usable; however, all of the old tags will still be broken, and will remain so forever, unless we rewrite history for webflo/drupal-core-require-dev. That's not something that is usually done, but holding to the normal conventions will only serve to keep most of the tags in that project unusable, save by projects that employ the workaround. If we do rewrite history, then we break every site that used the workaround. This is a discussion we'll need to have in that repo once there is a solution committed in Drupal.

@ greg.1.anderson

Can we not go with the 1.4.x-dev solution?
It's not ideal but will be following on from the equally not ideal situation that has been around for 3+ years.

@Simon Peacock: You are right, per #31 we should use ^1.4@dev, not ^1.4. If we fix only behat/mink-selenium2-driver today, though, we might just break again tomorrow if/when behat/mink switches to their 1.8.x branch. Moving forward with fixes for both behat/mink-selenium2-driver and behat/mink means we fix the four failures in #24. We can't assume those will be fixed in the upstream, because Drupal was depending on unstable dev releases that are not going to be maintained.

Our other option here is to fork behat/mink-selenium2-driver and behat/mink, and make our own stable tag on the exact commits we are using. I don't think that's a great idea; fixing the four test failures is a better path. I don't think I'll have time to look at that today, but hopefully someone can pick up that task.

Instead of depending on a dev branch (moving target) depend on a stable with patches. That would have documented what the requirement really is. Looking at the commits since 1.3.1 that still can be done. Just create a patch that contains the needed changes since 1.3.1 and specify the patch and pin on 1.3.1.

I don't think that we can patch dependencies in drupal/drupal. I could be wrong about that. We could potentially apply the fix in a post-install hook et. al.

I also made an appeal in the upstream to recreate the 1.3.x-dev tag in a way that would fix the old Drupal stable release tags. They were disinclined earlier, but we will see.

I tried using ^1.7@dev as the version constraint for behat/mink; unfortunately, this does not work for us, because 1.7.1 already exists, and it older than the commit we are using. This syntax behaves differently than 1.7.x-dev, and will downgrade to the available stable release (1.7.1) due to our "prefer dist" setting. Similarly, ^1.8@dev does not work at the moment, because there are no 1.8 tags, and 1.8.x-dev does not map to dev-master.

It seems that we are sort of stuck here unless we get stable tags in the upstreams. I made a request for a stable tag in behat/mink. It looks like the upstream projects are amenable to the plan, but we don't know how long it will take.

> Instead of depending on a dev branch (moving target) depend on a stable with patches.

This is what we do on our Drupal projects when a contrib module's stable version doesn't work, but it's -dev version does work. We depend on the stable version and add the patch file to composer.json.

Depending on a -dev branch breaks stuff, as this issue proves. All point releases of Drupal 8.x that use a -dev in composer.json need to be updated to remove those failing (or about to fail) "requirements".

> That would have documented what the requirement really is.

+1 I'm strongly in favor of self-documenting code.

greg.1.anderson in #48
This syntax behaves differently than 1.7.x-dev, and will downgrade to the available stable release (1.7.1) due to our "prefer dist" setting.

No surprise there! 1.7.x-dev is a discrete version (branch or tag), not a version constraint. A version is taken as is. With version constraint you let composer decide what version qualifies. Settings like minimum_stability and prefer_stable influence that decision.
They are not the only ones that have effect, but AFAIK not effected by "prefer dist".

The patch failed.

# patch -p1 < 3078671-36.patch
patching file composer.json
Hunk #1 FAILED at 9.
1 out of 1 hunk FAILED -- saving rejects to file composer.json.rej
patching file composer.lock
Hunk #1 FAILED at 4.
Hunk #2 succeeded at 8101 (offset 4601 lines).
Hunk #3 succeeded at 8120 (offset 4601 lines).
Hunk #4 succeeded at 8133 (offset 4601 lines).
Hunk #5 succeeded at 8154 with fuzz 1 (offset 4601 lines).<code>
and then
<code># composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested package behat/mink-selenium2-driver 1.3.x-dev exists as behat/mink-selenium2-driver[dev-master, 1.4.x-dev, v1.0.0, v1.0.1, v1.0.2, v1.0.3, v1.0.4, v1.0.5, v1.0.6, v1.1.0, v1.1.1, v1.2.0, v1.3.0, v1.3.1] but these are rejected by your constraint.

Is there no QA in the Drupal core project? This breaks everyone's sites.

A new perspective which works for me. :) I hope to help everyone.

@tjtj This is the QA you are participating in. Status Needs Work does mean it is not usable at the moment. Suggest to wait for Needs review and green test results. Actually, RTBC might be the one for you to wait on, even better Fixed.

@ ilchovuchkov

Looks like the patch you have supplied is for 8.7. This issue is for 8.8.
There is a child issue for 8.7.
But it looks like we are waiting to see what happens upstream as @greg.1.anderson has implied above.

Waiting for things to happen upstream sounds like postponed to me!

composer.json required changes.

Add composer.lock as well.

I fix the issue by myself today. I want to help which is need the fix now, and today. :)
Thank you.

Committing #58 would not help anyone install Drupal 8.7.7 or earlier with webflo/drupal-core-require-dev, so my vote would be to wait and do a fix that will be lasting, and commit that before Drupal 8.7.8.

Do we agree here that this issue is about a proper fix and doesn't need any more workarounds?

Do we need committer feedback to veto that?

If someone wants to advocate for #59, the first step is to make the tests pass. Once the tests pass, then someone who did not work on the patch and wants it committed can set the status to "reviewed and tested by the community" (after testing it, of course). After that, a core committer will commit it to core if they agree it is the right thing to do.

I am -1 on committing #59 because it does not help people trying to install 8.7.7. We will probably have stable tags for behat/mink and behat/mink-selenium2-driver shortly. If we do not, then I think we should fork those repositories and use the fork in 8.7.8 and onwards until the stable tags are made available.

Note also that there is a parallel effort to get a 1.3.x-dev branch re-added to behat/mink-selenium2-driver, which will help people trying to install 8.7.7 (and earlier) if successful.

Marking "postponed" on upstream stable tags, per consensus in Composer in Core Initiative meeting.

How is this postponed?? Currently it's not possible to install drupal 8 with composer using instructions from https://www.drupal.org/node/2718229

For problems with installing drupal-composer/drupal-project use their issue queue. This queue is for drupal !

Hey, from official drupal docs:

There are a number of ways that you could install Drupal using composer, however the recommended approach (especially for beginners to Composer) is to use the composer template at drupal-composer/drupal-project.

So maybe we have to update documentation to not include that?

Recommended way to install simply doesn't work now.

It does work. Just check their issue queue for the workaround!

Please refrain from further derailing this issue!

@karolrybak: the correct status for this issue is "postponed" because we are waiting for something outside of this issue to happen (stable tags on the upstream project) before we roll the next patch.

If for some reason someone wanted to advocate to take action on this issue, the right way to do it would be to set the status back to "Needs Work" to vote for fixing the tests in #59, or set the status back to "Needs Review" if a new patch with a new fix is suggested. As previously mentioned, though, committing #59 would not make it easier to install Drupal 8.7.7, so there is no point in changing the issue status to "Needs Work". Similarly, changing the issue status to "Active" is not going to make people work on this issue harder. We're working on it, the work simply isn't happening here at this point in time.

To help folks who are struggling with this problem, I have updated the issue summary with workarounds that can be taken right now to get your site to install with Composer. Please bear with us as we work toward a lasting solution. We should have something ready in time for 8.7.8.

Still missing the policy change for core development: don't require a moving target, use stable release optionally with patches.

As for the follow up: settings minimum-stability and prefer-stable should be removed. At the time this was introduced there was a poor understanding of release management in the eco-system. Currently, there is a much better understanding. The default for minimum-stability is Stable making prefer-stable = true redundant. Allowing anything in development is not something considered appropriate today. You should avoid things in development. When you have no choice you can express that on the version constraint (@dev, @alpha, @beta, @rc) of that particular dependency. With the eco-system now understanding to create Stable releases, they should be used. Needing something in development should be the exception and specified on the dependency version constraint.

+1 to #70.

I'm aware of the workaround, but why do we even need those external packages like selenium to install d8 in a recommended way? It's clearly getting out of hand with dependencies and if we don't acknowledge that we'll have a real problem soon.

For some time drupal-project was a way to go, right now it simply does not work. How can we make sure that the installation is up to date and secure other way? While drupal docs still says it's the best way to go?

Thanks for much more in depth replies, greg.1.anderson, mmjvb glad to know it's being worked on !

EDIT Didn't see your second reply.

That is what this issue is about: Preventing these kind of issues by not allowing dependencies on a moving target. The change in policy is to prevent this from happening again. For selenium the solution needs to be ^1.4@dev, for Mink there is no solution yet.

You don't need to convince people to solve this. This issue wants to solve it for D8.8.

For now drupal-project is still the way to go. Obviously, with --no-dev when you are not doing code development. Or removing the dev requirement to prevent mistakes. When doing development, for the moment you need that additional requirement bringing that development alias for selenium back. For a developer that shouldn't be a big deal.

Really, though, we should never depend on dev releases of external components. If we just cannot live without a commit on some branch of some project that does not have a stable release, we should make a non-maintained fork for the express purpose of having a project we control to depend on. Users shouldn't wake up Labor Day morning to discover that sites with no new commits are suddenly broken. That was a mistake of the past. Moving forward, we can avoid having it happen again.

I tried the --no-dev option and got a syntax error. Posted to github. Surely the recommended install should not be a development install. --no-dev should be the default.

Absolutely agree, but we have no choice now. As soon as new stable releases are available we can remove @dev from the constraint. The errors in #24 suggest depending on commits in Mink after Stable. Suggest to try only selenium to confirm tests are green.
In that case Mink needs a patch with fixes Drupal testing depends on. Otherwise they must be unrelated.

Not sure why is it even required to install drupal right now ??

webflo/drupal-core-require-dev 8.8.x-dev requires behat/mink-selenium2-driver 1.3.x-dev -> no matching package found

I could write a whole blog about the word "development" in Composer - and maybe I will. The problem is that this term is used for two vastly different concepts:

• Stability flags, e.g. "minimum-stability": "dev", 1.3.x-dev, ^1.4@dev, etc.
• Components that are only needed for testing, e.g. require-dev, autoload-dev, etc.

By default, Composer will install the components that are only needed for testing when you update or install your project. You must use the --no-dev flag to avoid this.

Stability flags, on the other hand, default to stable by default, although Drupal chose to change the default to "development" (a mistake, in my opinion).

These two things are often conflated, which leads to some confusion.

@karolrybak: Just remove webflo/drupal-core-require-dev from your Drupal site for now. You probably don't need it. I advocated for it to be removed by default in https://github.com/drupal-composer/drupal-project/issues/477.

Re #27, the tests in #24 were a mistake. I thought the tags I were testing were more recent than the commits in Drupal's composer.lock file, but on subsequent investigation discovered they are earlier. This is why the tests failed. I expect everything should work just fine without further adjustment once we have stable tags in the upstreams.

If we never get stable tags in the upstreams, we do have a choice. We can fork our own copy of these projects. I don't think that will be necessary, though; it looks like the maintainers are going to provide what we need pretty soon.

So looks like it's here
https://github.com/webflo/drupal/blob/8.0.x/core/vendor/behat/mink/compo...

Does this even belong in core?

@karolrybak: The project and lines you are looking for are:

• https://github.com/webflo/drupal-core-require-dev/blob/8.7.7/composer.js...
• https://github.com/webflo/drupal-core-require-dev/blob/8.7.7/composer.js...

The first step is to fix the problem in Drupal Core, as drupal-core-require-dev is a generated package that builds its releases by reading the dependencies from every Drupal release.

Unfortunately, composer is a developer tool, not deployment. There is no way to set it to --no-dev, not even using environment variables. The maintainers declined the request to change the default. Could be part of phase 2 of composer initiative, creating plugin to change default to no-dev instead of dev. Or create your own shell command.

Indeed, this issue is not resolved yet. No surprise webflo/drupal-core-require-dev 8.8.x-dev is having the problem, drupal 8.8-dev is still having the problem. It is postponed because there is no solution yet. Proposed solution requires upstream work, hence postponed. FYI, drupal-core-require-dev is generated out of drupal core. As this is a problem in drupal core it appears in drupal-core-require-dev.

As a workaround, I solved it locally by adding the lost package information to my private repository (based on satis). Not sure if possible, but adding it to the packages section of the composer.json file of drupal-composer/drupal-project could works as a temporary solution until a new approach is found.

This is the behat/mink-selenium2-driver (1.3.x-dev) package information:

        {
          "type": "package",
          "package": {
            "name": "behat/mink-selenium2-driver",
            "version": "dev-master",
            "source": {
                "type": "git",
                "url": "https://github.com/minkphp/MinkSelenium2Driver.git",
                "reference": "8684ee4e634db7abda9039ea53545f86fc1e105a"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/minkphp/MinkSelenium2Driver/zipball/8684ee4e634db7abda9039ea53545f86fc1e105a",
                "reference": "8684ee4e634db7abda9039ea53545f86fc1e105a",
                "shasum": ""
            },
            "require": {
                "behat/mink": "~1.7@dev",
                "instaclick/php-webdriver": "~1.1",
                "php": ">=5.3.1"
            },
            "require-dev": {
                "mink/driver-testsuite": "dev-master"
            },
            "type": "mink-driver",
            "extra": {
                "branch-alias": {
                    "dev-master": "1.3.x-dev"
                }
            },
            "autoload": {
                "psr-4": {
                    "Behat\\Mink\\Driver\\": "src/"
                }
            },
            "notification-url": "https://packagist.org/downloads/",
            "license": [
                "MIT"
            ],
            "authors": [
                {
                    "name": "Konstantin Kudryashov",
                    "email": "e******t@gmail.com",
                    "homepage": "http://everzet.com"
                },
                {
                    "name": "Pete Otaqui",
                    "email": "p**e@otaqui.com",
                    "homepage": "https://github.com/pete-otaqui"
                }
            ],
            "description": "Selenium2 (WebDriver) driver for Mink framework",
            "homepage": "http://mink.behat.org/",
            "keywords": [
                "ajax",
                "browser",
                "javascript",
                "selenium",
                "testing",
                "webdriver"
            ],
            "time": "2018-10-10T12:39:06+00:00"
          }
        }

#3079333: webflo/drupal-core-require-dev prevents installing 8.7.7 using composer

what helped me https://github.com/drupal-composer/drupal-project/issues/511 - until this is cleared:

"require": {
....,
"behat/mink-selenium2-driver": "dev-master as 1.3.x-dev"
},

Please stop spamming this issue with workarounds for 8.7, this issue is about 8.8. For 8.7 see https://www.drupal.org/project/drupal/issues/3078904

@manuel.adan Very interesting workaround. Wonder whether it is possible to have multiple branch-aliases. For those having a private repository this would be the perfect solution. Having the change available instantly without a need to change anything in your projects. For the general public it would probably need to be provided by the facade on d.o.

For projects having a path repository pointing to a local folder it would be usable as well. Expect the package repository in your project to work as well, haven't tried it though. Suspect the simple require dev-master as 1.3.x-dev in the main project to be simpler for most people.

I think that commiserating about 8.7.x here is fair. I don't know that it was necessary to open the backport issue before we have a solution here; it's more convenient to have one place for discussions.

Also, as a heads up, it looks like behat/mink is going to make a 1.8.0 release, which means that the 1.7.x-dev branch alias we are currently depending on is also going to disappear.

I added a request that the maintainers create a persistent 1.7 branch before removing the 1.7.x-dev branch alias.

The 1.3 branch has been created for behat/mink-selenium2-driver, so everyone's builds should automatically start working again.

Still waiting for stable releases from behat/mink-selenium2-driver and behat/mink so that we can apply lasting fixes here. Downgrading to "major" since builds are not actually broken at the moment -- but we are still at risk for builds breaking if behat/mink removes the 1.7.x-dev branch alias before creating the 1.7 branch, but at this point I don't think that will happen. All the same, we should get onto the stable tags as soon as they are available, as that's the right thing to do.

Can confirm install is working now with composer.

Still all the external dependencies should be reviewed and reduced as noted in #75.

This is just a warning sign and if we don't put more thought into dependencies this could become a security risk too.

See #2899825: Release and support cycles for PHP dependencies for discussion of third party dependencies, specifically in relation to release cycles.

Thanks for the reference to 2899825. We are lobbying for stable releases of behat/mink and behat/mink-selenium2-driver that are the same, or functionally the same as the commit we currently pin to in our composer.lock file. I think that we should adopt these stable releases in our composer.json as soon as they are available, regardless of the release cycle. Hopefully, though, this will happen well in advance of the 8.8.0-alpha freeze.

Hello,

It works (#58). Please replace in your composer.json:

-        "behat/mink-selenium2-driver": "1.3.x-dev",
+        "behat/mink-selenium2-driver": "dev-master as 1.3.x-dev",

behat/mink-selenium 2-driver has fixed their issue upstream. There is no need to apply #58.

We should keep this issue focused on removing the - dev aliases from our composer.json/lock

Yes, #96 is actually an anti-pattern now, because it will break again once Drupal moves to a stable release. Anyone who has already applies workarounds for the behat/mink-selenium2-driver issue should remove them now.

I updated the issue summary to reflect this advice.

Try thispatch to composer.json

#100 is the same as #96. You are actually better off at this point NOT doing that, and instead just use 1.3.x-dev. Using dev-master will float to the most recent dev commits for this component (which may in the future break with Drupal, e.g. could pick up 2.x commits if they start a 2.x branch), whereas the 1.3 branch should not receive any further commits.

Add a remaining task to remove the test and guard.

Another (bad) reason to do this: while I know this is an anti pattern but as long as composer has the speed it has, there's no other practical way for us but to commit vendor into the git repo and if you are doing that then these branches carry their own .git which makes for trouble. We have

    "scripts": {
        "remove-git-submodules": "find vendor -type d -name .git | xargs rm -rf",           

in our composer.json to work around. I'll be glad to remove it.

There's a random error caused by the current release of behat/mink on PHP 7.4 - see #3115000: Random fail in \Drupal\Tests\node\Functional\PagePreviewTest::testPagePreviewWithRevisions on PHP 7.4

We can do this now! https://github.com/minkphp/Mink/issues/725#issuecomment-597699833

Bye-bye icky code...

index 9b0a881f21..802a169dab 100644
--- a/composer.json

--- a/composer.json
+++ b/composer.json

Can we also get rid of
"minimum-stability": "dev",
or should that be in a follow-up? It doesn't seem we are 100% decided on that. And at the least, it would be nice to see a patch that has it to see how things fly with it. But follow-up is fine too.

Better to file follow-up for #108
And summary needs polishing

Working on failure in #107

We can maybe just remove that test coverage as it is testing logic that no longer exists?

Nice unit test failures.... updating the tests. Not 100% sure about how useful they actually are.

@Berdir I think the tests are testing something. They are testing how the meta packages copy dependencies and in the case of \Drupal\Composer\Generator\Builder\DrupalPinnedDevDependenciesBuilder this results in a specific version as per lock file and in the case of \Drupal\Composer\Generator\Builder\DrupalDevDependenciesBuilder it results in copying the constraint.

It also tests that things in the dev require section get moved into the regular require section.

Should reference be updated?

           'source' =>
           [
             'type' => 'git',
             'url' => 'https://github.com/minkphp/Mink.git',
-            'reference' => 'a534fe7dac9525e8e10ca68e737c3d7e5058ec83',
+            'reference' => 'e6930b9c74693dff7f4e58577e1b1743399f3ff9',
           ],

locked reference is `e1772aabb6b654464264a6cc72158c8b3409d8bc`, i copied from https://github.com/minkphp/Mink/commit/e6930b9c74693dff7f4e58577e1b17433..., it's wrong.

Update git reference

Looks good, test changes all make sense. Also glad there is finally a release we can use.

Could use a CR and a release note. I'm assuming we want to backport this to at least 8.9.x and maybe 8.8.x once it's in 9.0.x since it's only a dev dependency.

Fixed the release note and created the change record - https://www.drupal.org/node/3119264

Adding review credit for @mmjvb and @karolrybak

Committed d3b2a6f and pushed to 9.0.x. Thanks!

Moving to 8.9.x for backport.

Here's the 8.9.x backport. Note that there's been an 1.8.1 behat/mink release - there's nothing of consequence in it - as far as I can see it is only a docs change ... but here's a 9.0.x patch so 9.0.x stays as up-to-date as 8.9.x.

Missed a bit.

Is “v1.2.3” a semantic version?
No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example: git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.

See https://semver.org/#is-v123-a-semantic-version

I am wondering, should 1.8.0 be used which is under the require section of composer.json, instead of v1.8.0? inside file composer.lock, it's fine as the file is auto-generated always. And yes, as @alexpott said to me over Slack, it's fake, does not matter which to use here.

+++ b/composer.lock
@@ -3528,30 +3531,33 @@
+            "version": "v1.8.1",

@@ -3704,16 +3710,16 @@
+            "version": "v1.4.0",

+++ b/core/tests/Drupal/Tests/Composer/Generator/BuilderTest.php
@@ -68,7 +68,7 @@ public function builderTestData() {
+            'behat/mink' => 'v1.8.0',

+++ b/core/tests/Drupal/Tests/Composer/Generator/Fixtures.php
@@ -84,12 +84,12 @@ protected function composerLock() {
+          'version' => 'v1.8.0',

Re #129/ @jungle - no we should not do that here's why:

1. +++ b/composer.json
   @@ -16,9 +16,9 @@
   +        "behat/mink": "^1.8",
   

   This is what is in the composer.json.

2. +++ b/composer.lock
   @@ -3528,30 +3531,33 @@
   +            "version": "v1.8.1",
   

   This is what composer writes to its lock files. We have 0 control over that. It is just how it is. We do not write composer.lock files and when we fake them we should copy what they do. Hence the v1.8.0 in the test fixture

Also look at the current pinned dependencies file - full of a mishmash of version constraints that we have no control over because it is up to the dependencies to tag their releases how they like.

Thanks, @alexpott, agree with you on #130

Checked the link in #131 of file/composer/Metapackage/PinnedDevDependencies/composer.json and found that they are not true semantic versions according to #129 See below:

  "require": {
        "behat/mink-goutte-driver": "v1.2.1",
        "fabpot/goutte": "v3.2.3",
        "jcalderonzumba/gastonjs": "v1.0.2",
        "jcalderonzumba/mink-phantomjs-driver": "v0.3.2",
        "mikey179/vfsstream": "v1.6.8",

A few packages are using v1.2.3-like versions under the require section of a composer.json file, I just have not used that way before.

So my question becomes that whether to remove the prefix v to follow the semantic versioning strictly for packages under the require and require-dev sections of composer.json file(s).

@jungle well certainly not in this issue. You can open another issue if you like but for me it's a closed won't fix because these version strings are determined by composer so they are what we need to pin on.

Re #132 Composer understands/accepts/handles the v prefix. If upstream maintainers want to use v1.2.3 (like all of symfony) there is nothing we need to do. And given that those versions are actual tags in a git repository, it is better that we leave them exactly as is.

Semver isnt deterministic. There is no 'correct' or 'proper' semver, because it is really just a contract, between humans, on how we should behave. Software that interfaces with semver expectations, like composer can either be rigid, and only accept a narrow definition of what constitutes a 'version string', or, it can be somewhat looser, to allow for all the historical releases that were 'pretty close to semver' by adding things like a v.

Extra double comment edited out.

I visually compared #117 and #127 and the only differences are in composer.lock, which is expected.

The 9.0.x followup patch in #125 is also trivial.

Both patches are RTBC.

Many thanks to @Ryan and @alexpott for your replies and explanations! I am happy having 'v' to stay in now!

Committed the follow-up to 9.0.x, and the 8.9.x backport.

We should probably discuss whether or not to backport to 8.8.x - it is a library update, but it is one which gets us on a nice stable version during 8.8.x LTS and just a dev dependency. I'm not sure whether it's worth it or not for 8.8.x

A patch against 8.8.x. In case it's needed.

So what's the final decision, port it to 8.8.x or not?

For me, I'd vote for yes.

"behat/mink": "^1.8" is a dev dependency package, it's no harm obviously to have a higher minor and stable version.

@jungle thanks! As a patch here - that's right status to get rtbc and commiter's eyes

Tentative RTBC. I compared #141 and #127 and the only differences are in composer.lock - the hash and some irrelevant changes in the abandoned Zend framework packages.

However, we don't normally upgrade dependences in patch releases as far as I know - and I am not sure I see the need here. Drupal 8.8 end of life is in December and I don't see any benefit in upgrading this dependency.

If we are going to backport #3135247: Composer's "prefer-stable" setting cannot be relied on to produce a stable release to 8.8.x, then we need to do this issue first as a prerequisite. Otherwise, it prevents folks from using drupal/core-dev.

I think we should commit this on 8.8.x even if we do not backport #3135247.

@catch and I discussed this and agreed to backport it to 8.8.x. While we wouldn't normally do a minor update to dependencies in a patch release, this is updating dev dependencies only from (in one case) a random commit on a broken branch to a stable release that's fixed.

It will also make things easier for the recent pain surrounding our metapackage templates and things updating incorrectly because of prefer-stable / minimum-stability: "dev".

Compared #141 to the previous patches and committed it to 8.8.x. Thanks!

Note if this gets reverted from 8.8.x then we need to revert or adjust #3123933: Determine whether ComposerProjectTemplatesTest is testing the internet, and if it is, avoid that on 8.8.x because that commit depends on this one.

Very glad to have this in 8.8.x, so folks can switch to using minimum stability: stable and still use drupal/core-dev if they want.