Skip to content

Conversation

@jescalada
Copy link
Contributor

@jescalada jescalada commented Sep 14, 2025

Fixes #1150, built on top of #1166.

Not all tests were perfectly refactored from Chai/Mocha -> Vitest. Some required partial or total rewriting to get them to play nice.

Some tests, specifically the proxy-related tests (proxy.test.ts, testProxy.test.ts and most importantly testProxyRoute.test.ts) have been very problematic for some reason - the tests in testPush.test.ts seem to fail in the CI when some of the proxy tests execute prior. They fail on the first execution locally, and then pass without issue (maybe a caching/cleanup problem).

Coverage has dropped somewhat to 80.5%, but we should see an increase after removing unused/untested code such as plugin stuff.

Note that the CI is failing due to the new Blue Oak license.

jescalada and others added 30 commits August 24, 2025 09:39
Co-authored-by: j-k <dev@j-k.io>
Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: j-k <dev@j-k.io>
Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: j-k <dev@j-k.io>
Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: j-k <dev@j-k.io>
Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
@jescalada
Copy link
Contributor Author

@pGrovesy @grovesy This is the other big PR that could use a review! 🙏🏼

Copy link
Contributor

@kriswest kriswest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A huge contribution (reading it took half a day!).

A few questions about type overrides as and whether some can be removed for type safety in the tests. The schema docs generator also needs to be run (type generator was run). There's also a few places you could use vitest's assert to simplify checks.

I spotted a number of things that aren't really within the scope of this PR and commented on them. If on reviewing them you agree, either you or I should create issues to resolve those.

const config = loadFullConfiguration();

if (!config.cookieSecret) {
throw new Error('cookieSecret is not set!');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should possibly make cookieSecret required in the config schema. Currently none of the top-level properties are required... but then that lets you validate a file full of overrides (as long as the defaults cover everything that is actually required). However, its leading to our generated type for the config having these properties as optional.

This may be worth some further thought - we could have two top-level schemas (for the defaults and for override files) that reference the same defs for top-level properties I suppose. That would give us two different typescript types to use, as appropriate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting these top-level properties as required ends up causing a bunch of ConfigLoader-related tests to fail because of the missing properties... I lean towards making them optional for flexibility since those test cases were likely based on actual use cases 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hence the comment about having two top-level schemas, one for the full config with all required elements required, and one for overrides... Makes maintenance more complex however. I wonder if we could achieve it in Typescript alone with either the Required<type> or Partial<type> utiulity types? I think wrapping Required around the current generated type would make all the top-level properties required and give us the type safety where we need it without extra schema?

WDYT?

export const getSessionMaxAgeHours = (): number => {
const config = loadFullConfiguration();
return config.sessionMaxAgeHours;
return config.sessionMaxAgeHours || 24;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above - no default needed if it has to be in the defaults and we have a type expressing that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked into setting default values for these in the schema config, but unfortunately the generated types don't enforce the defaults anywhere.

Maybe we could have a constants.ts file to centralize these - or perhaps a defaults.ts file to make sure these are consistent? Right now we have default values scattered between the proxy.config.json, config/index.ts and a few other spots as a fallback for the getSomeConfigValue() functions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous comment about using Required. Types can't enforce the defaults, but they can enforce a value being set. If the value is required to be set (in a full configuration) then no default is needed. That could be a neat solution, i.e. functions like loadFullConfiguration returning Required<GitProxyConfig> - although they might need to confirm that all those values are set on load and throw an error if not (e.g. because someone messed with the default config).

],
},
});
expect(res.status).toBe(401);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be a 403 - not an issue for this PR

],
},
});
expect(res.status).toBe(401);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be a 403

Comment on lines +228 to +239
{
label: 'I am happy for this to be pushed to the upstream repository',
tooltip: {
text: 'Are you happy for this contribution to be pushed upstream?',
links: [],
},
checked: true,
},
],
},
});
expect(res.status).toBe(401);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be a 403

],
},
});
expect(res.status).toBe(401);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be a 403, etc. will stop marking them here

@@ -0,0 +1,35 @@
import { defineConfig } from 'vitest/config';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a vitest config file for the cli tests as well?

jescalada and others added 18 commits November 18, 2025 09:05
Co-authored-by: Kris West <kristopher.west@natwest.com>
Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: Kris West <kristopher.west@natwest.com>
Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: Kris West <kristopher.west@natwest.com>
Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: Kris West <kristopher.west@natwest.com>
Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: Kris West <kristopher.west@natwest.com>
Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: Kris West <kristopher.west@natwest.com>
Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Co-authored-by: Kris West <kristopher.west@natwest.com>
Signed-off-by: Juan Escalada <97265671+jescalada@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Migrate tests from Mocha + JS to Vitest + TS

4 participants