Remove Project Browser-specific styling

Hey @phenaproxima

Like we discussed on Slack, this is where I would land, see https://git.drupalcode.org/project/gin/-/merge_requests/588

I actually strongly suggest we don't go with !588, because it's not clear that we will keep that template around at all. Instead, we should rely on the pre-render functions of the ProjectBrowser render element. I've implemented that in !586.

@phenaproxima I think we have different ideas in mind here.

I want to keep PB styling aroudn for pre 2.0.0-alpha10 versions, that's what MR !588 is doing. If 2.0.0-alpha10 or greater Gin will not ship any PB relevant styling at all. We're just ensuring we'll not break the experience for users which are still on an older PB version here.

phenaproxima → closed merge request !586

Closed !586 after some Slack discussion with @saschaeggi.

Manually tested !588 on Drupal 11.x-dev, with Project Browser 2.0.x-dev and this MR checked out.

With CSS and JS aggregation disabled, I unfortunately did see Gin attaching its styles in the page header of /admin/modules/browse/drupalorg_jsonapi:

<link rel="stylesheet" media="all" href="/themes/gin/dist/css/components/project_browser.css?ssckx4" />

So I think this might need another pass.

Never mind -- this works if I put a version: 2.0.0-alpha10 element in Project Browser's info file.

So this won't work with dev heads, but it should work as intended for tagged releases. Do we need to worry about that?

@phenaproxima I've update the MR so that it also works with dev-releases.

Wanted to switch to composer's version parser but get an exception with \Composer\Semver\VersionParser::normalizeStability('2.0.0-alpha10');:

InvalidArgumentException: Invalid stability string "2.0.0-alpha10", expected one of stable, RC, beta, alpha or dev in Composer\Semver\VersionParser::normalizeStability() (line 92 of /var/www/html/vendor/composer/semver/src/VersionParser.php). 

Looks like the version parser doesn't like "alpha10"? Do you have any advise on how this package should be used? Otherwise we leave it as is, as all combinations I've tried are now working as expected.

Use parseStability(), not normalizeStability(), and pass it the full version string. That should do what you want!

Closed all threads in the MR and the semver constraint check is working as expected. It correctly behaves for e.g. 2.0.0-alpha9, 2.0.0-alpha10, and even if no version information is available, assuming that this is then a later version than alpha10.

Back to NR.

Pulled changes and gave this another test by visiting /admin/modules/browse/drupalorg_jsonapi with Gin as the admin theme, and looking for /themes/gin/dist/css/components/project_browser.css in the page source.

✅ Project Browser version unknown (i.e., dev branch): CSS not there
✅ With version: 2.0.0-alpha10: CSS not there
✅ With version: 2.0.0-alpha8 CSS is there

So this is good to go from my perspective.

Because this worked for me, and passed tests -- and is also a rather important blocker for Project Browser -- I am tentatively RTBCing this.

@saschaeggi told me in Slack that he'd like to get review from more than just me, and that's totally fine; nonetheless, I don't see any real reason to keep this in "needs review" while we get additional sign-offs.

This makes perfect sense to me!

Thanks, included in 4.0.6 release! 🖖

Automatically closed - issue fixed for 2 weeks with no activity.