What should we call this repo?

[sndrs]

csnx is an awkward acronym of client side Nx. It has (at least) two big problems:

1. it isn't strictly client side-focussed
2. use of Nx is contingent implementation detail that could easily change

You have to call a repo something and it seemed the least worst option at the time, but now we're considering publishing everything in /libs as one mega-package, the problem is back.

A package called @guardian/csnx makes a lot of sense, in that it's clear where the code lives, why a feature is included in the package (it's in the repo) and adoption paves the way to moving codebases into the monorepo.

But it's an awful name, for the same reasons above (except it's not even Nx once it's published).

So let's find something better.

• if you have a suggestion, please comment it below
• if you see one you like, please upvote it

[mxdvl]

javascript

What that ties all of the code in this repo together is that it will be run by a JavaScript runtime, whether in a client or server. It can be confusing that the code itself is written in TypeScript…

[sndrs]

hmmmt that's a very good counter...going to make another suggestion

[tjmw]

I wonder, for non-JS languages, what would the benefit be of keeping that code in this repo/package be? I'm sure this is an oversimplification but from my (limited!) understanding it sounds like the complexity we're trying to tackle here relates to NPM package releases and keeping dependencies in sync? Would that be relevant for non-JS stuff, and is there an argument that that should that be a line in the sand (non-JS doesn't go here?)

[mxdvl]

My thinking is that if you’re writing code that will run in a JavaScript runtime, you’ll get the most benefit from being in this monorepo, and this monorepo also exposes an eponymous library on NPM that is to be consumed by other projects that have not yet chosen it as their home.

@jamesmockett – I think that it’s unlikely that the source code of Source will move away from JavaScript, as it’s the language of the web. Whether it exposes tokens in an intermediary format seems more of an implementation detail. It may also be that Source design tokens may come from somewhere else…

[sndrs]

it doesn't seem beyond the bounds, though, that if DCR lived here, it would be useful have frontend too. in that case, keeping a play app in a repo called javascript seems obviously wrong, even though moving the code there might not be.

[jamesmockett]

I agree it's unlikely that the web version of Source is going to move away from JavaScript entirely, but it's possible that we make it more framework agnostic and make greater use of native web technologies rather than React and Emotion. (Or at least provide that as an option. Stylesheets and custom properties for non-React projects for example.) There's also a desire to have an equivalent for native apps so it would make sense that they all live together under the Source umbrella. This almost sounds like an argument for Source going back to being a separate repo which is possibly an entirely different conversation.

[sndrs]

****** (i.e. some non-descriptive name)

given @jamesmockett's excellent counter argument to javascript, is something non-descriptive that doesn't set bounds a good idea?

I'm generally not in favour of this - it feels like you're not dealing with the fact that you don't understand what you're proposing.

is that the case here? should we be able to describe what this repo does?

or is it actually quite nebulous, in a good way?

[sndrs]

this was chatgpt's suggestions:

1. Batch
2. Stack
3. Heap
4. Array
5. Cluster
6. Bundle
7. Cache
8. Set
9. Pool
10. Pack
11. Group
12. Chain
13. List
14. Block
15. Queue
16. Series
17. Matrix
18. Folder
19. Library
20. Record

they are all too loaded/descriptive to my mind

[sndrs]

things with good names, off the top of my head: pasteup, source, typewriter typerighter, ophan

[sndrs]

i asked chatgpt to come up with 20 spondees (2 syllables, equally stressed, e.g. ophan) related to collections, number 10 was haystack :)

"i think it's in haystack, good luck finding it though"

[jamesmockett]

The BBC have some wonderfully obscure repo names:
https://github.com/bbc/simorgh

Named Simorgh after the Persian mythological bird. The Simorgh is the amalgam of many birds (and in some accounts other animals) into one.

[ParisaTork]

Off topic, but:

Simorgh comes from the Shahnameh (The Book of Kings). It is Iran's national epic poem, a seminal work of Persian literature and a very important artifact of Persianate and Middle Eastern history, analogous to the Odyssey and the Iliad, but more wide-reaching in the Eastern world.

One of the cool things about the Shahnameh are the wonderful illustrations. Here's an image of Zal in Simorgh's nest:

Fun fact: I am also named after a Persian mythological creature, called a Pari. And because my dad is my dad, my cousins were called Sharzad and Roxanna.

[arelra]

cs

I don't think 'client-side' necessarily excludes server-side code if we think of 'client-side' work as fullstack.

So it describes an orientation rather than a hard architectural boundary.

[mxdvl]

Are you suggesting fs / fullstack, then? 😉

---

I wonder if we could spell things out? Is client-side too verbose?

[arelra]

fullstack

noooo :)

[arelra]

Throwing some more out there:

rendering, gui, goo

Naming is hard.

[sndrs]

we did used to have a goo tool, remnants here https://github.com/guardian/frontend/blob/0c1cd1a410bbadd5ad0530250a8149034e23bc77/docs/01-start-here/03-how-to-deploy.md?plain=1#L28.

dcr also began life as guui (though no one except me liked it afaict!)

[sndrs]

how about vienna - it's easy to spell and tops the quality of life index

[sndrs]

or wien (austrian name)

[jamesgorrie]

My suggestion would be to name it what it is for future folk to be able to guess what it does. My next question then is, what is this repo intended for?

(see edit of comment if you want to see me publicly thinking aloud on this)

[jamesgorrie]

A retort (thanks @sndrs)

[coldlink]

tofu? A food which can be used in all sorts of flavours and textures. Very woke too.
It's short, and i'm sure you could turn it into an acronym if you really wanted?
e.g. (T)ypescript (O)r (F)rontend (U)Is

[mxdvl]

This. A million times this. 🤯 🍜

[tjmw]

Love it. I've been trying to think of a recursive acronym we could retrofit a la Gnu, best I've come up with is: (T)ofu's (O)ur (F)ullstack (U)niverse 😄

[raphaelkabo]

Love it. I've been trying to think of a recursive acronym we could retrofit a la Gnu, best I've come up with is: (T)ofu's (O)ur (F)ullstack (U)niverse 😄

TOFU Organises Fullstack Usability?

[sndrs]

Types, Objects, Frameworks, Utilities

[sophie-macmillan]

I think the issue is that the packages contained in the monorepo are so broad. It currently contains packages that

• render shared ui (e.g. source-react-components)
• contains shared config (e.g. prettier and ts-config)
• contains some sort of other shared functionality (e.g. identity-auth)

That makes it hard to come up with a name thats descriptive enough as to what they all do, without it being too limiting in the future as to what we can include.

So I have a fairly generic suggestion (maybe too generic) of @guardian/shared or @guardian/common

[OllysCoding]

Loads of different and interesting ideas in here so far - but I think the conversation has been quite focussed on what goes in the monorepo, instead of why it goes into the monorepo, therefor I'd like to start the discussion on the idea that a monorepo is usually a series of libs & apps that all depend on each other in various ways - the best reason to put your new lib in CSNX is because if it's using CSNX code, it's just easier.

So, names that are around inter-dependency, linking & sharing seem like the way to go in my opinion (if it's not tofu of course)

• linked
• collab
• sharer
• loops
• chainlink
• galaxies (oh dangit, this one is already taken)

Okay so I admit ... I don't actually have any good name ideas for this theme, but I do like the idea of the name being themed around the idea that things go in this repo because they're all sharing with each other, relying on each other, etc.

[OllysCoding]

Okay so after some more thinking I've come up with some things I think are actually okay:

• flock - in reference to packs of animals who all live & rely on one-another
• habitat - focussing on the idea that this is a home for many things which might share an ecosystem (would have to borrow this from the sainsburys subbrand though: https://www.habitat.co.uk/)
• symbiosis - bit more self explanatory
• commune - living together, helping one-another
• fungi

[mxdvl]

I like flock and fungi!

[jamesmockett]

I'm not so keen on fungi as it has associations with decay which is probably not what we want 😬

As another submission, flock and commune reminded me of the name of a nearby art gallery: collective

[OllysCoding]

I like collective too!

[coldlink]

Thinking of more journalistic related terms similar to @guardian/source

press -> like the machine which prints the paper, and this project is "machine" which does that online
angle -> from the word meaning the perspective from which the news article is written, and this project provides the angle for how code should be used?
stand -> like a newsstand, a place where all the projects/code live, like all the papers/magazines on an old newsstand