feat: add support for targetting specific workspaces #1212

MalickBurger · 2024-08-23T11:58:48Z

fixes #1126

jkowalleck

some things require chen. see my remarks.

also, please add proper unit tests

CONTRIBUTING.md

src/cli.ts

src/builders.ts

MalickBurger · 2024-08-26T05:50:07Z

some things require chen. see my remarks.

also, please add proper unit tests

Happy to do the changes. I would think some integration tests would be required for this change as it is not really feasible to test it in isolation due to the logic effectively sitting on the npm ls side.

I agree with the requirement of testing. I spent some time initially before making the PR going through the existing unit and integration tests and it is not very clear to me how we should go about adding tests for new functionality. For example, I do not see tests for several of the CLI options (such as --short-PURLs).

Could you provide a bit of a guide regarding how we should lay out tests for new functionality going forward as well as a brief of how the existing integration tests work and how they are structured. I intend on making additional PRs in the future for other issues and features so this would be very beneficial for me (and I'm sure other community members).

jkowalleck · 2024-08-26T07:43:55Z

@MalickBurger, for adding additional integration tests,

you would add new setups here, if needed: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/demo
Then, add the appropriate npm ls ... run here: https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/.github/workflows/npm-ls_demo-results.yml
have the npm ls ... result data gathered via a CI (Github action/workflow).
you can dispatch the action in your repo here: https://github.com/MalickBurger/cyclonedx-node-npm/actions by dispatching the workflow (you might need to enable workflows for your repo)
download the action artifacts and add them here: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results
remove unnecessary data via https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results/_duplicates-cleaner (might require a back-merge or rebase to pull the scripts in)

since you are planning on adding conditional parameters in the npm ls call, you need to incorporate this in the existing testing processes somehow.

caused by #1212 --------- Signed-off-by: Jan Kowalleck <[email protected]>

MalickBurger · 2024-09-16T14:30:28Z

@MalickBurger, for adding additional integration tests,

you would add new setups here, if needed: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/demo

Then, add the appropriate npm ls ... run here: https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/.github/workflows/npm-ls_demo-results.yml

have the npm ls ... result data gathered via a CI (Github action/workflow).
you can dispatch the action in your repo here: https://github.com/MalickBurger/cyclonedx-node-npm/actions by dispatching the workflow (you might need to enable workflows for your repo)

download the action artifacts and add them here: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results

remove unnecessary data via https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results/_duplicates-cleaner (might require a back-merge or rebase to pull the scripts in)

since you are planning on adding conditional parameters in the npm ls call, you need to incorporate this in the existing testing processes somehow.

Looking at this, could you provide some testing support for an existing argument that is passed to npm ls by the plugin which I could then base my additional tests on? It would be easier and cleaner for a code maintainer to set these up so there is a standard to follow going forward for community members.

jkowalleck · 2024-09-29T18:41:29Z

@MalickBurger, for adding additional integration tests,

you would add new setups here, if needed: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/demo

Then, add the appropriate npm ls ... run here: https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/.github/workflows/npm-ls_demo-results.yml

have the npm ls ... result data gathered via a CI (Github action/workflow).
you can dispatch the action in your repo here: https://github.com/MalickBurger/cyclonedx-node-npm/actions by dispatching the workflow (you might need to enable workflows for your repo)

download the action artifacts and add them here: https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results

remove unnecessary data via https://github.com/CycloneDX/cyclonedx-node-npm/tree/main/tests/_data/npm-ls_demo-results/_duplicates-cleaner (might require a back-merge or rebase to pull the scripts in)

since you are planning on adding conditional parameters in the npm ls call, you need to incorporate this in the existing testing processes somehow.

Looking at this, could you provide some testing support for an existing argument that is passed to npm ls by the plugin which I could then base my additional tests on? It would be easier and cleaner for a code maintainer to set these up so there is a standard to follow going forward for community members.

will do. just bare with me, it may take a while

jkowalleck · 2024-10-29T15:31:21Z

will do. just bare with me, it may take a while

I am currently working on a solution. Will ping as soon as I have something for you.

src/cli.ts

jkowalleck · 2024-10-31T09:53:58Z

@MalickBurger ,

I've overhauled the integration tests.
It would currently be enough to add your tests, showcasing that the intended parameters are sent to npm-ls. This could be done here: https://github.com/CycloneDX/cyclonedx-node-npm/blob/main/tests/integration/cli.args-pass-through.test.js

you might add something like

// region workspace
['workspace not supported npm 6', `6.${rMinor}.${rPatch}`, ['--workspace my-wsA', '--workspace my-wsB'], [...npm6ArgsGeneral]],
['workspace npm 7', `7.${rMinor}.${rPatch}`, ['--workspace my-wsA', '--workspace my-wsB'], [...npm7ArgsGeneral, '--workspace my-wsA', '--workspace my-wsB']],
['workspace npm 8', `8.${rMinor}.${rPatch}`, ['--workspace my-wsA', '--workspace my-wsB'], [...npm8ArgsGeneral, '--workspace my-wsA', '--workspace my-wsB']],
['workspace npm 9', `9.${rMinor}.${rPatch}`, ['--workspace my-wsA', '--workspace my-wsB'], [...npm9ArgsGeneral, '--workspace my-wsA', '--workspace my-wsB']],
['workspace npm 10', `10.${rMinor}.${rPatch}`, ['--workspace my-wsA', '--workspace my-wsB'], [...npm10ArgsGeneral, '--workspace my-wsA', '--workspace my-wsB']]
// endregion workspace

PS: i've also prepared demo data for additional integration tests. I might add them as soon as the basic pass-through tests are done

jkowalleck · 2024-12-11T14:35:52Z

@MalickBurger , i see you've rebased this feature branch recently.
Are planning on integrating the needed tests as described here ?

MalickBurger · 2024-12-11T14:47:52Z

@MalickBurger , i see you've rebased this feature branch recently. Are planning on integrating the needed tests as described here ?

Hi @jkowalleck, yes I have been busy recently but am getting back to this now. Will be posting updates soon.

src/cli.ts

tests/integration/cli.args-pass-through.test.js

src/cli.ts

jkowalleck · 2024-12-24T14:40:59Z

merged in the latest master, fixed some merge conflicts.
did another round of review. result: there are open questions and issues

MalickBurger · 2025-01-08T14:25:26Z

merged in the latest master, fixed some merge conflicts. did another round of review. result: there are open questions and issues

Will take a look and update over the next few days when I have a chance

jkowalleck · 2025-01-13T17:41:20Z

seams like some tests are failing.

MalickBurger · 2025-01-17T07:20:58Z

seams like some tests are failing.

Should be resolved now.

jkowalleck · 2025-01-26T09:15:45Z

i am considering this feature to be integrated and marked as "experimental".
this means all related CLI switches are disabled per default, and are remarked as experimental.

MalickBurger · 2025-02-11T06:45:40Z

Hi @jkowalleck just want to find out where we stand regarding this PR. From my side I believe it is ready to merge.

jkowalleck

something seams not right

jkowalleck · 2025-02-11T11:51:20Z

src/builders.ts

+      }
+    }
+
+    // No need to set explicitly if true as this is default behaviour


Suggested change

// No need to set explicitly if true as this is default behaviour

// No need to set explicitly if true as this seams to be default behaviour for `npm-ls`

jkowalleck · 2025-02-11T11:56:09Z

tests/integration/cli.args-pass-through.test.js

+      ['workspaces disabled npm 8', `8.${rMinor}.${rPatch}`, ['--no-workspaces'], [...npm8ArgsGeneral, '--workspaces=false']],
+      ['workspaces disabled npm 9', `9.${rMinor}.${rPatch}`, ['--no-workspaces'], [...npm9ArgsGeneral, '--workspaces=false']],
+      ['workspaces disabled npm 10', `10.${rMinor}.${rPatch}`, ['--no-workspaces'], [...npm10ArgsGeneral, '--workspaces=false']],
+      ['workspaces disabled npm 11', `11.${rMinor}.${rPatch}`, ['--no-workspaces'], [...npm11ArgsGeneral, '--workspaces=false']]


though it is not documented, it still has effect.
it is the same as npm ls --workspaces=false

The default behaviour by npm ls is to include all workspaces if present, this requires no explicit argument (no need for --workspaces=true, which actually errors if there are no workspaces). If you want to disable this and exclude workspaces you can do this using --workspaces=false. Now this means there is actually three modes for this, the default (undefined) which includes workspaces if they are present, explicitly true which errors if there are no workspaces, and explicitly false which ignores workspaces completely.

Now in terms of how we pass this logic through the cdx plugin we have two options, either we name the argument --workspaces to match npm ls but now we need to tell users that the default for this boolean is undefined which actually acts the exact same as true except it won't cause an error if there are no workspaces (quite confusing and unclear for users in my opinion).

Or the second option is to add a argument which explicitly allows you to disable resolving workspaces using --no-workspaces.

Another reason I did it this way is because of how poor the documentation for npm ls is for this specific argument, this is what the official docs say:

[workspaces](https://docs.npmjs.com/cli/v11/commands/npm-ls#workspaces) Default: null Type: null or Boolean Set to true to run the command in the context of all configured workspaces. Explicitly setting this to false will cause commands like install to ignore workspaces altogether. When not set explicitly: Commands that operate on the node_modules tree (install, update, etc.) will link workspaces into the node_modules folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, unless one or more workspaces are specified in the workspace config.

Another reason I did it this way is because of how poor the documentation for npm ls is for this specific argument, this is what the official docs say:

[workspaces](https://docs.npmjs.com/cli/v11/commands/npm-ls#workspaces) Default: null Type: null or Boolean Set to true to run the command in the context of all configured workspaces. Explicitly setting this to false will cause commands like install to ignore workspaces altogether. When not set explicitly: Commands that operate on the node_modules tree (install, update, etc.) will link workspaces into the node_modules folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, unless one or more workspaces are specified in the workspace config.

How does a user determine what the default behaviour is from this documentation.

I see.

My suggestion: We use --workspaces and have it a boolean with default value of null. (like npm docs say)
if the value of options.workspaces is not null, then the value is passed to npm-ls.
And of course, our own help text should be meaningful. Unlike the one from npm-ls

What do you think?

I like it, I think its a good compromise, I will make the relevant updates

src/cli.ts

jkowalleck · 2025-02-11T12:18:01Z

src/cli.ts

+    ).default([], 'empty')
+  ).addOption(
+    new Option(
+      '--no-workspaces',


i still do not see how this comes together.
where comes this --no-workspaces from? I mean, npm knows -ws|--workspaces -and it defaults to null for this. and you can set tot to true/false ...
why does this option not mimic npm-ls options?

See above comment about Commander. Happy to change this to --workspaces it just makes it less intuitive for users in my opinion but if you want to always mimic npm ls then I will make the update.

please remove this option.
we tend to mimic npm-ls - and they dont call this out explicitely.

i still do not see how this comes together. where comes this --no-workspaces from? I mean, npm knows -ws|--workspaces -and it defaults to null for this. and you can set tot to true/false ... why does this option not mimic npm-ls options?

Npm ls does support it, test it out.

i still do not see how this comes together. where comes this --no-workspaces from? I mean, npm knows -ws|--workspaces -and it defaults to null for this. and you can set tot to true/false ... why does this option not mimic npm-ls options?

I don't follow you, this is best commander.js supports booleans unless we parse the value as a string and convert to a boolean tj/commander.js#344.

please remove this option. we tend to mimic npm-ls - and they dont call this out explicitely.

They also don't explicitly mention how workspace logic works by default but we are now telling users how that works through or params and README (which we have to do because it is not intuitive at all so they need some guidance)

please remove this option. we tend to mimic npm-ls - and they dont call this out explicitely.

They also don't explicitly mention how workspace logic works by default but we are now telling users how that works through or params and README (which we have to do because it is not intuitive at all so they need some guidance)

Additionally, without it, how will users disable the logic?

jkowalleck

i think some parts need discussion

jkowalleck · 2025-02-21T15:45:53Z

src/builders.ts

@@ -64,6 +67,9 @@ export class BomBuilder {
  flattenComponents: boolean
  shortPURLs: boolean
  gatherLicenseTexts: boolean
+  workspace: string[]
+  includeWorkspaceRoot: boolean
+  workspaces?: boolean


Suggested change

workspaces?: boolean

workspaces: boolean | null

From the builder perspective we can treat this as undefined as well and thus don't pass to npm ls (default behaviour) but will change it if you prefer.

jkowalleck · 2025-02-21T15:46:57Z

src/builders.ts

@@ -86,6 +92,9 @@ export class BomBuilder {
    this.flattenComponents = options.flattenComponents ?? false
    this.shortPURLs = options.shortPURLs ?? false
    this.gatherLicenseTexts = options.gatherLicenseTexts ?? false
+    this.workspace = options.workspace ?? []
+    this.includeWorkspaceRoot = options.includeWorkspaceRoot ?? false
+    this.workspaces = options.workspaces


Suggested change

this.workspaces = options.workspaces

this.workspaces = options.workspaces ?? null

jkowalleck · 2025-02-21T15:49:07Z

src/builders.ts

+    // No need to set explicitly if false as this is default behaviour
+    if (this.includeWorkspaceRoot) {
+      if (npmVersionT[0] >= 8) {
+        args.push('--include-workspace-root=true')


Suggested change

args.push('--include-workspace-root=true')

args.push('--include-workspace-root=${this.includeWorkspaceRoot}')

Unnecessary I believe, as we are in the if statement and know it is true.

src/cli.ts

src/builders.ts

jkowalleck · 2025-02-21T16:37:54Z

src/cli.ts

@@ -238,6 +270,20 @@ export async function run (process: NodeJS.Process): Promise<number> {
    throw new Error('missing evidence')
  }

+  if (options.workspaces === false) {
+    if (options.workspace !== undefined && options.workspace.length > 0) {


options.workspace is never undefined, right?

Suggested change

if (options.workspace !== undefined && options.workspace.length > 0) {

if (options.workspace.length > 0) {

Yes, this is remnant of previous logic, will remove the check

jkowalleck · 2025-02-21T16:43:18Z

src/cli.ts

@@ -238,6 +270,20 @@ export async function run (process: NodeJS.Process): Promise<number> {
    throw new Error('missing evidence')
  }

+  if (options.workspaces === false) {
+    if (options.workspace !== undefined && options.workspace.length > 0) {
+      myConsole.error('ERROR | Bad config: `--workspace` option cannot be used when `--no-workspaces` is also configured')


remove this custom output, throwing an error is enough

Suggested change

myConsole.error('ERROR | Bad config: `--workspace` option cannot be used when `--no-workspaces` is also configured')

jkowalleck · 2025-02-21T16:44:08Z

src/cli.ts

+  if (options.workspaces === false) {
+    if (options.workspace !== undefined && options.workspace.length > 0) {
+      myConsole.error('ERROR | Bad config: `--workspace` option cannot be used when `--no-workspaces` is also configured')
+      throw new Error('bad config')


lets copy the error message npm-ls uses.

Suggested change

throw new Error('bad config')

throw new Error('Can not use --no-workspaces and --workspace at the same time')

jkowalleck · 2025-02-21T16:47:40Z

src/cli.ts

+  if (options.includeWorkspaceRoot) {
+    if (options.workspace.length === 0 && options.workspaces !== true) {
+      myConsole.error('ERROR | Bad config: `--include-workspace-root` can only be used when `--workspace` or `--workspaces` is also configured')
+      throw new Error('bad config')


not true. please get rid of this error constraint.
reason:
if i want my workspace root only, i could set all other workspace options to empty/false ...
npm ls honors this behaviour.

am i wrong here?

Well it depends on how you look at it, the "--include-workspace-root" param only has an impact or relevance if you are specifying "--workspace=x" or "--workspaces" because all other scenarios we are not dealing with workspaces explicitly so why use the param?

In this case the logic is slightly wrong because I am not handling the default behaviour of "workspaces" which is effectively true (but is actually null.........).

The reason I included this was to help guide users a bit on how it all works together, so they don't do things like always pass in "--include-workspace-root" thinking they need to even though root dependencies are always included unless under certain circumstances (which I document in the error and README/cli).

MalickBurger · 2025-02-21T18:16:58Z

I think we are conflicting slightly on how this should be implemented because I am trying to design this in a way that is the most intuitive and yet still flexible experience for users. The aim is for it to be clear what the default behaviour is and how they can modify this behaviour if they wish.

The way you would like this done is to mimic npm ls exactly which I still don't fully understand since most users of the plugin wouldn't really care how the internals work they just want a tool that can create sboms for npm projects as easily as possible.

In an ideal world we could both have our way but I don't think it is the case here because the behaviour of npm ls with regards to workspaces is non intuitive and a bit of a black box (it also changes between version 7 and newer versions).

Before I go back and rewrite the logic again let's please fully decide how this is going to look, how we are going to explain it to users, and what default logic will be for all combination of workspace related parameters.

jkowalleck · 2025-02-23T11:18:53Z

The way you would like this done is to mimic npm ls exactly which I still don't fully understand since most users of the plugin wouldn't really care how the internals work they just want a tool that can create sboms for npm projects as easily as possible.

This PR and a reading npm docs and changelogs showed ma, that even npm developer had no clear vision how things should be working. the idea of workspaces might look simple at first, but it has so many "use cases", more than they imagined at first.

I had the idea to mimic npm, because i thought users knew how their npm worked, but were just not sure how to generate SBOM from the data they had.
If we mimicked npm, then we would have not to take care of all the strange edge cases every other npm version introduced - we would lay this into the hand of the users.

My idea was to go the "easy" path - from a product owner's perspective - as all responsibility would be shifted to the users. Especially with workspaces, I would expect to have experienced users who knew what they do.
Our discussions showed me, that my idea was bad from a user's perspective. They now would need to learn about their own npm and its edge cases. Now they would need to understand aspects they maybe did not even care about. This could be considered as bad user experience.

I think I understand your point, and you convinced me.
If your idea was to produce consistent results over all supported npm versions, then the current tests might be insufficient. For this reason, I would say:
implement it the way you envisioned it. 👍, and if needed, get rid of current tests

After the implementation is done, we might see which kind of test data is required and how it can be provided.
Since the feature is experimental, i'd suggest adding test data in a separate pullrequest later.

mapau · 2025-03-05T09:22:26Z

@MalickBurger and @jkowalleck what is the status here? I would like to use the cyclonedx-node-npm with some projects that uses npm workspaces. Let me know if I can help here in any way. I will try, the branch build on my projects for now.

MalickBurger · 2025-03-05T09:39:28Z

@MalickBurger and @jkowalleck what is the status here? I would like to use the cyclonedx-node-npm with some projects that uses npm workspaces. Let me know if I can help here in any way. I will try, the branch build on my projects for now.

Hi @mapau, I will be getting back to this later in the week, we are close (hopefully) to having this PR finalized. Happy if you would consider doing some testing once complete?

Signed-off-by: MalickBurger <[email protected]>

MalickBurger · 2025-03-07T17:44:27Z

Hi @jkowalleck,

I have refactored my changes based on our last discussion. I have simplified the logic and have tried to make it as simple and intuitive as possible to users while still mimicking npm ls where possible. I have designed it in such a way that users do not need to have an indepth understanding of npm ls or knowledge on which version they are running.

I have updated the tests but I need to do a few manual sanity tests as well however I will wait for now incase I need to make any additional changes.

MalickBurger requested a review from a team as a code owner August 23, 2024 11:58

MalickBurger force-pushed the feat/workspace-support branch from 4ac8c52 to a26d8da Compare August 23, 2024 12:16

jkowalleck requested changes Aug 25, 2024

View reviewed changes

CONTRIBUTING.md Outdated Show resolved Hide resolved

src/cli.ts Outdated Show resolved Hide resolved

src/builders.ts Show resolved Hide resolved

jkowalleck mentioned this pull request Sep 4, 2024

tests: WS and project extra unused #1215

Merged

jkowalleck added a commit that referenced this pull request Sep 4, 2024

tests: WS and project extra unused (#1215)

d4490c8

caused by #1212 --------- Signed-off-by: Jan Kowalleck <[email protected]>

jkowalleck requested changes Oct 30, 2024

View reviewed changes

src/cli.ts Outdated Show resolved Hide resolved

MalickBurger force-pushed the feat/workspace-support branch from d95dee9 to 052b2a6 Compare November 4, 2024 10:45

MalickBurger force-pushed the feat/workspace-support branch from 052b2a6 to e7c1f1d Compare December 11, 2024 14:16

jkowalleck self-requested a review December 11, 2024 14:55

jkowalleck added the enhancement New feature or request label Dec 11, 2024

jkowalleck mentioned this pull request Dec 11, 2024

[FEAT] support workspaces #1126

Open

MalickBurger force-pushed the feat/workspace-support branch from e7c1f1d to a5ff5bc Compare December 12, 2024 13:00

jkowalleck requested changes Dec 24, 2024

View reviewed changes

src/cli.ts Outdated Show resolved Hide resolved

src/cli.ts Outdated Show resolved Hide resolved

tests/integration/cli.args-pass-through.test.js Outdated Show resolved Hide resolved

jkowalleck requested changes Dec 24, 2024

View reviewed changes

src/cli.ts Outdated Show resolved Hide resolved

src/cli.ts Outdated Show resolved Hide resolved

MalickBurger force-pushed the feat/workspace-support branch from ae6e4d3 to a300d13 Compare January 9, 2025 14:51

jkowalleck self-requested a review January 13, 2025 17:37

MalickBurger force-pushed the feat/workspace-support branch from 4b610a3 to 99114f6 Compare January 17, 2025 07:19

jkowalleck mentioned this pull request Jan 29, 2025

Tool name: CycloneDX SBOM for npm aboutcode-org/workshop#50

Open

60 tasks

MalickBurger force-pushed the feat/workspace-support branch from 99114f6 to 8e86e56 Compare February 4, 2025 07:20

jkowalleck requested changes Feb 11, 2025

View reviewed changes

jkowalleck reviewed Feb 11, 2025

View reviewed changes

jkowalleck requested changes Feb 21, 2025

View reviewed changes

feat: add support for targetting specific workspaces

02824c2

Signed-off-by: MalickBurger <[email protected]>

MalickBurger force-pushed the feat/workspace-support branch from 11817e0 to 02824c2 Compare March 7, 2025 17:40

	// No need to set explicitly if true as this is default behaviour
	// No need to set explicitly if true as this seams to be default behaviour for `npm-ls`

	this.workspaces = options.workspaces
	this.workspaces = options.workspaces ?? null

	args.push('--include-workspace-root=true')
	args.push('--include-workspace-root=${this.includeWorkspaceRoot}')

	if (options.workspace !== undefined && options.workspace.length > 0) {
	if (options.workspace.length > 0) {

	throw new Error('bad config')
	throw new Error('Can not use --no-workspaces and --workspace at the same time')

feat: add support for targetting specific workspaces #1212

Are you sure you want to change the base?

feat: add support for targetting specific workspaces #1212

Conversation

MalickBurger commented Aug 23, 2024 • edited by jkowalleck Loading

jkowalleck left a comment

Choose a reason for hiding this comment

MalickBurger commented Aug 26, 2024

jkowalleck commented Aug 26, 2024 • edited Loading

MalickBurger commented Sep 16, 2024

jkowalleck commented Sep 29, 2024

jkowalleck commented Oct 29, 2024

jkowalleck commented Oct 31, 2024 • edited Loading

jkowalleck commented Dec 11, 2024

MalickBurger commented Dec 11, 2024

jkowalleck commented Dec 24, 2024

MalickBurger commented Jan 8, 2025

jkowalleck commented Jan 13, 2025

MalickBurger commented Jan 17, 2025

jkowalleck commented Jan 26, 2025 • edited Loading

MalickBurger commented Feb 11, 2025

jkowalleck left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkowalleck Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MalickBurger Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkowalleck Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkowalleck left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MalickBurger Feb 21, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkowalleck Feb 21, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MalickBurger commented Feb 21, 2025

jkowalleck commented Feb 23, 2025

mapau commented Mar 5, 2025

MalickBurger commented Mar 5, 2025

MalickBurger commented Mar 7, 2025

MalickBurger commented Aug 23, 2024 •

edited by jkowalleck

Loading

jkowalleck commented Aug 26, 2024 •

edited

Loading

jkowalleck commented Oct 31, 2024 •

edited

Loading

jkowalleck commented Jan 26, 2025 •

edited

Loading

jkowalleck Feb 11, 2025 •

edited

Loading

MalickBurger Feb 11, 2025 •

edited

Loading

jkowalleck Feb 11, 2025 •

edited

Loading

jkowalleck left a comment •

edited

Loading

MalickBurger Feb 21, 2025 •

edited

Loading

jkowalleck Feb 21, 2025 •

edited

Loading