Chrome logger

[oscarotero]

@mindplay-dk created this package to send log messages to google chrome.
Maybe, the package should provide the middleware, but I leave it here anyway, just in case.

[mindplay-dk]

We do have this integrated in our stack - I'm not sure how though.

Digging through some code now to see how it was integrated - maybe there's another component that could be moved to this package...

[mindplay-dk]

I looked into it - we don't even have a component for this, because it's so trivial.

class ChromeLoggerMiddleware implements ServerMiddlewareInterface
{
    private $logger;

    public function __construct(ChromeLogger $logger)
    {
        $this->logger = $logger;
    }

    public function process(ServerRequestInterface $request, DelegateInterface $delegate)
    {
        return $this->logger->writeToResponse($response);
    }
}

In our stack, it's a little bit different because we have more dependencies.

But I suppose this simple implementation would work for most cases, so maybe I should just check that in and add a simple test?

[mindplay-dk]

Oh, now I recall why this isn't in there - for the same reason I hold off anything else that depends on PSR-15. It's unstable. That means I can't tag a 1.0 release of a package that depends on it, at least not without expecting another major release every time PSR-15 makes a BC booboo.

I don't want the logger package itself to have a BC break for no reason other than the middleware-signature changing, so if I were to publish the middleware now, it would need to be a separate package, so that the break is there, an not in the logger component itself...

Hmm....

[oscarotero]

Ok, I see.
If it's so trivial, I think a middlewares/chrome-logger makes no sense here, because the middleware can be provided with the package.

I recomend to tag the version 0.1 (BC are allowed in 0.x versions).

[schnittstabil]

In my very own opinion, ChromeLogger should neither support PSR-15 nor PSR-7, simply because it violates SRP on the project level – in contrast to PSR-3, which is essential for ChromeLogger.

Or in other words: Why must ChromeLogger depend on PSR-7?
The PSR-7 code is somehow isolated (see the lines L107-L114) and removing the PSR-7 dependency would make the project more attractive for other projects in my opinion, e.g. in conjunction with Symfony, but we can think of any future non-PSR-7 library too:

use Symfony\Component\HttpFoundation\Response;

$response = new Response();

// this needs getHeaderValue() to become public:
$response->headers->set(ChromeLogger::HEADER_NAME, $chromeLogger->getHeaderValue());

– Just my two cents.

[mindplay-dk]

Why must ChromeLogger depend on PSR-7?

Well, there's emitHeader for non-PSR projects. If you want Symfony-integration, then getHeaderValue is protected for that reason and you can extend the class for your framework.

It's designed for PSR-7 and I'm not going to BC break to remove that. I doubt anyone would care if the PSR-7 interfaces get installed - if that makes the package unattractive, then, meh.

If it's so trivial, I think a middlewares/chrome-logger makes no sense here, because the middleware can be provided with the package.

@oscarotero I agree, but don't want to inherit BC breaks from PSR-15, so I'll wait until it's stable.

I know that BC are allowed in 0.x versions according to SemVer, but package managers (Composer, npm) do not work that way, which is why I wrote and adhere to this :-)

[oscarotero]

but package managers (Composer, npm) do not work that way

In my experience, both npm and composer are semver compilant. For example, a version ^0.1 does not update to 0.2 but the version ^1.1 do update to 1.2.

[schnittstabil]

I believe @oscarotero is right. For example, see madewithlove/elasticsearcher ^0.4.0

You can also test npm semver at https://semver.npmjs.com

[mindplay-dk]

Guys, I know how npm and Composer work :-)

What I'm saying is, I believe they attribute more meaning to 0.x.y revision numbers than what is defined or required by semver.

Per semver.org:

4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

I take this as meaning "any release may contain breaking changes".

5. Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

I take this as meaning "the public API isn't defined at all prior to 1.0.0", and "version numbers prior to this release are not dependent on the public API".

If that's not what they meant, it's extremely ambiguous, confusing and poorly written.

Furthermore, sections 6, 7 and 8, which define the version increment rules, define these explicitly for x.y.z | x > 0 only - there are actually no rules anywhere defining the meaning of y and z in 0.y.z, and it clearly can't mean the same thing as y and z in the defined meanings for x.y.z | x > 0, since both are for backwards-compatible changes.

In my experience, both npm and composer are semver compilant.

Well, they're not not compliant, they're just assigning a more specific meaning to 0.x.y release numbers than is apparently defined by semver.

For example, a version ^0.1 does not update to 0.2 but the version ^1.1 do update to 1.2.

Well, exactly - according to my understanding of sections 4 and 5, under semver, ^0.1.0 should basically mean =0.1.0, since there is no commitment to any public API, and thereby any change could be a breaking change. In practice, this is of no use to anybody, and I never understood why it was defined that way - the description I wrote explicitly defines the meaning of 0.x as meaning merely "feature-incomplete", because why would you tag a release at all unless there's some kind of working public API and some level of commitment to at least indicating when that public API goes through breaking changes?

Essentially, for 0.x releases, the second digit is treated by npm and Composer as the major version number, the third digit as minor, which means that "patch" revisions presumably are not a thing for 0.x releases, but they don't specify anywhere, and even the FAQ doesn't specify what precisely is meant by "incrementing the minor version", in the following:

How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

If the second digit is the minor version, and you think npm and Composer work according to the spec, essentially they're saying "every release should be incompatible with the previous".

I don't know, maybe it's just really poorly written, but I had enough of the ambiguities and complexity, and finally decided to rewrite the damn thing - our developers need clear guidelines they can actually follow.

:-)

[schnittstabil]

Yes, you are right, the ^ operators of npm and composer are not compatible to semver in every single detail. But they work as everybody expect them. I believe I miss the crucial point of you explanation; on the surface you described at https://simversion.github.io how npm's and composer's ^ work (w/o the -alpha stuff), didn't you?

npm Caret Ranges:

[…] Many authors treat a 0.x version as if the x were the major "breaking-change" indicator. […]
Caret ranges are ideal when an author may make breaking changes between 0.2.4 and 0.3.0 releases, which is a common practice.

composer Caret:

The ^ operator behaves very similarly but it sticks closer to semantic versioning, and will always allow non-breaking updates. […] For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0.

[schnittstabil]

Btw, you probably know that, the ~ operators of npm and composer differ in their meaning:

• npm: ~1.2 := >=1.2.0 <1.3.0
• composer: ~1.2 := >=1.2 <2.0.0

[oscarotero]

under semver, ^0.1.0 should basically mean =0.1.0

This is not entirely true, ^0.1.0 means ~0.1.0 (or 0.1.x), meaning that if the version 0.1.1 or 0.1.2 is released, composer/npm will update it.

Maybe semver.org is a bit confusing about the 0.x releases and SimVersion makes a better description about how a 0.x version should work. But as far as I know, everybody expect the same behaviour in semver, I mean: possible BC in y and no BC in z. I mean, the innovation in SimVersion is to describe a behaviour that was expected (but not fully explained) in semver.

Anyway, I still don't understand why not tag the 0.1.0 version of ChromeLogger although it does not include support for PSR-15. At least, is better than relying in a dev-master version (IMHO).