Panther's issues live in the Symfony monorepo, and its readme asks you to donate to a wildlife fund

Issues and pull requests belong in the Symfony monorepo

The resources section is three links long, and one of them is the most important thing in the readme.

Issues and pull requests are to be filed in the main Symfony repository, not in this one. Both links point at the framework's issue tracker and its pull request area.

That single fact explains the rest of the repository's shape. The readme is short because the framework's documentation carries the usage material. The repository has one example file because the framework's documentation carries the examples. And the version history here is a subtree mirror of a much larger project with its own release cadence.

It also means the two places a contributor would instinctively look are the wrong ones. The stars live here, the documentation lives in the framework, and the code lives here, but the conversation happens in neither of the two repositories a newcomer would expect.

The three links are documentation, contributing guidance, and that issue tracker. The contributing link is also a framework page rather than a file in this repository, so the contribution process is the framework's process with this package as one part of it.

For an evaluator the practical consequence is that this repository tells you almost nothing about how actively the code changes or what its open problems are, because the evidence for both is somewhere else entirely. The only activity signal available here is the release list and the last commit date.

The heading element is empty and the logo sits beside it

The readme opens with a level-one heading element that contains no text at all.

That is not a stylistic choice visible on the rendered page; it is an empty element in the file. Whatever was meant to go inside it is not there.

There is a plausible explanation sitting in the repository root: an SVG image file named after the project. A centred level-one heading containing that image is a common way to put a logo at the top of a readme, and the empty heading looks like the residue of exactly that, with the image either never committed into the heading or dropped from it.

So the first thing a reader encounters is an empty heading, and the most likely intended content for it is two directories away.

The rest of the file is more disciplined than that opening suggests. The description of what the library does takes two sentences, one naming the two platforms it targets and one naming the protocol it speaks. The named browsers are two. The claims are about capability rather than about quality, except for one.

That exception is a single sentence of pure superlative with nothing attached to it. It is the only claim in the readme with no supporting detail, and it stands out precisely because everything around it is specific: the protocol is named, the browsers are named, the two projects it derives from are named. A reader who wants to know what justifies that adjective finds nothing after the sentence, because the next one is about how to report a bug.

The project describes itself three different ways

The same library is characterised three ways within a few lines, and the differences are small but they are real.

The repository description calls it a browser testing and web crawling library. The readme's own summary line calls it a browser testing and web scraping library. The sentence underneath refers to scraping websites, and the credits paragraph repeats scraping in describing the announcement post that introduced it.

So crawling appears once, in the metadata, and scraping appears everywhere a human would read. They are not synonyms in practice. Crawling suggests traversing a site systematically; scraping suggests extracting data from pages. A library can do one, both, or neither, and the two words make different promises about what a reader will get.

The difference matters most for the half of the project that is not testing. For end-to-end tests the distinction is irrelevant, because the driver is being told which element to click. For the scraping half it is the whole point, and it is the half the readme describes in a single sentence before moving on to bug reports.

It is worth noting what the readme does not claim. It does not say which browsers beyond the two it can drive, whether concurrent sessions are supported, whether a headless mode is available, what happens when an element is not found, or how it handles a page that never finishes loading. For a library whose entire value is automating a real browser, the readme is unusually silent about the browser's failure modes.

The name is an animal and the readme asks you to help it

There is a section in this readme that has nothing to do with software.

It observes that many wild cat species are highly threatened, and asks readers who like the software to help by donating to a conservation organisation, linked by name. The wording includes a parenthetical: the real panthers.

That parenthetical is doing the work. The section exists because the library is named after an animal, and the author is being explicit that the appeal is about the animal rather than about the code. It is a small joke with a charity attached to it, and it is the only part of the file that is not about the library.

It is also, given the search results this project attracts, the single most useful thing in the readme. Almost every query this repository draws is somebody looking for the animal: whether a panther is a jaguar, whether panthers are friendly to humans, what the slang means. Alongside them sit queries for a bicycle brand, a motorcycle, a tank, a type of laptop, a crab, a fish, and an astronomical eclipse. One cluster is for electrical goods with the brand on them, including timers, surge protectors and battery chargers, and another is for marine steering kits and transom savers.

None of those searches will reach a developer, because the animal and the brand outrank a PHP library called the same thing. A reader who finds the readme by accident has no way to tell from the search result which of the seventeen meanings they wanted.

Three test configurations for three target runtimes

The root of the repository carries three test configuration files with the same base name and different suffixes, plus two further tools for checking code.

The base configuration is the conventional default. The other two have a version number appended. That naming pattern means the test suite is run against more than one target runtime, each with its own settings, rather than one configuration hoping to work everywhere.

For a library whose readme says nothing about supported versions, this is the most informative compatibility signal in the repository. Two extra configurations means at least two additional runtimes are tested, and a test that passes against a runtime is meaningfully different from code that merely parses under it.

The two other tools are a static analyser configuration and a code style configuration. So the quality gate is three-part: a formatter to normalise style, an analyser to find type and logic problems, and the test runner itself. That is a fuller toolchain than most libraries of this size assemble, and it is all configured by files at the root rather than documented anywhere in the readme.

What is absent is equally informative. There is no configuration for how to launch a browser, no fixture describing a test page, and no file in the repository that shows where the two named browsers are expected to come from. A new contributor reading only the root would know the project tests against real browsers and would have no idea how that is arranged.

One WebDriver client underneath, one JavaScript tool as inspiration

The credits paragraph names two antecedents and they are not the same kind of thing.

The first is the library it is built on: a WebDriver client for this language, linked alongside a general reference to several other free-software libraries, with a link to the announcement post that lists them. So the driver protocol implementation is somebody else's project, and this one sits on top of it.

The second is something it was inspired by: a WebDriver-based testing tool written in JavaScript. The readme is careful about the difference, saying it was inspired by rather than built on, which is the honest phrasing for a design influence.

The protocol itself is the standards body's specification, linked directly. That is the right foundation for this kind of library, because it means the library is a client rather than an opinion: anything that speaks the protocol can talk to the same browsers, and the language-specific work is confined to translating messages into calls.

Two browsers are named, both of them from the same vendor-independent mainstream, and nothing else is mentioned. No headless mode, no mobile browser, no remote grid. For a testing library that is a meaningful boundary, since browser grids and device emulation are where the awkward requirements usually surface.

The sponsorship is also worth noting for its form. The library was sponsored by a cooperative rather than a company, and created by a named individual. For a project that sits inside a larger framework's repository, that combination is consistent with the framework ecosystem rather than unusual within it.

One example file, and everything else is a documentation link

The examples directory contains a single file.

That is the entire worked example this repository offers, for a library whose two advertised uses are writing browser-driven tests and scraping sites. Whatever that file demonstrates, it cannot demonstrate both, and it is not referenced from the readme.

Everything else a new user would want is a link out. The documentation link points at the framework's end-to-end testing guide rather than at anything specific to this library, which means the first click lands on a page about testing in general and the reader has to find the part that applies here.

The readme does have what a change record usually provides, in the form of a change log file at the root. That is more than several projects in this set carry, and for a library whose major versions move the platform floor it is the file a reader most wants.

Putting the pieces together, the repository is a well-maintained subtree: three quality tools, three test configurations for three runtimes, a change log, a single example, and a readme that routes everything else to the surrounding framework. The one thing it does not do is describe itself, and the one thing it does that nothing else does is ask for donations on behalf of an animal.

Editorial conclusion

Panther suits a team writing end-to-end tests against a real browser in a PHP codebase, or scraping a site from one, and who would rather speak the standard driver protocol than a bespoke automation API. Before adopting it, check five things. File your issues and pull requests in the Symfony monorepo rather than in this repository, or they will go to the wrong place. Decide which browsers you need, because only Chrome and Firefox are named. Expect the examples to be thin, since the repository carries a single example file and points at framework documentation for everything else. Note that the test suite is configured per runtime version, which tells you the library is tested against more than one. And if you arrived searching for the animal, the fund it points to is the real one.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. symfony/panther on GitHub