add @guardian/libs code

[sndrs]

• adds the source code from @guardian/libs (https://github.com/guardian/libs)
• updates the VisibilityState type in the CWV tests to use TS's DocumentVisibilityState
• removes the old dev info from the readme
• updates generateSvg.logger.teams.ts script to match the CSNX node version, and accommodate changes in fix: remove type assertions from logger libs#384 that were missed here

[changeset-bot]

⚠️ No Changeset found

Latest commit: d39ea68

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[sndrs]

@mxdvl are you ok with the changes in ede6453? (hard to spot them because the file is also added)

[ob6160]

are these sections now covered by a more general monorepo readme? maybe we could link to where that is, if it exists?

[sndrs]

no, this readme is the info gets displayed on npm for example, so it's still needed here

[ob6160]

sorry — I was referring to the ones you removed

[sndrs]

no that's something we need to address, but probably beyond the scope of this PR?

[ob6160]

okay, is it recorded somewhere that we need to address this? (on trello or similar)

[mxdvl]

Thanks for updating the logger script!

Is it a problem at all that we have now lost git history? I'm assuming as we were squashing and merging, the change log is roughly equivalent.

[sndrs]

Is it a problem at all that we have now lost git history?

we'll always have the history in the original repo – do you think we need to manage bringing in the history for the code that moves here?

the conversations around this so far have tended towards concluding that history is useful to a point, but maybe not worth the noise it introduces in a migration like this (esp where the history starts again, but the earlier stages can be found in the old home)

[sndrs]

Is it a problem at all that we have now lost git history?

maybe it would be useful to add a link to the original repo in the merge commit – that way if someone is diving into the history of these files, at least they'd eventually reach that commit that would redirect them to the old repo and it's history

[mxdvl]

maybe it would be useful to add a link to the original repo in the merge commit – that way if someone is diving into the history of these files, at least they'd eventually reach that commit that would redirect them to the old repo and it's history

I think that would be very beneficial, along with a small explanation of the decision in the commit message and a link to the change log.

Contrary to many other repos, I would not expect people to rely on blame to delve into historical code, so a singular commit makes sense. Things that make this library unique are:

• 100% coverage
• extensive documentation
• strictest typescript checks
• versions and change log
• exports independent modules
• not driven by external business requirements

[OllysCoding]

along with a small explanation of the decision in the commit message and a link to the change log.

I'd agree with this - it's worth remembering as well that if you were bringing in the previous history, you end up with mis-matched PR #'s on the old commits, as they same PRs don't exist in the new repository.

As long as when navigating back to the end of the history in the new repo, you can get a link to the old repo & basic information on what's happened, this is likely better than having a lot of old history which doesn't link up well to the new repo