move test-support/index service container into other "modules"

[johncowen]

Description

Why

We are gradually moving things out of the application and into separate modules, when we spot things that are not currently in a module (or "pseudo app-module") but probably should be, we are moving them over there.

What

We spotted

kuma-gui/packages/kuma-gui/test-support/index.ts

Lines 1 to 34 in 6168e7e

	import { defaultKumaHtmlVars as htmlVars } from '@kumahq/config/vite'
	import { config } from '@vue/test-utils'
	import type { PluginDefinition, ComponentDefinition } from '@/app/vue'
	import type { ServiceConfigurator } from '@kumahq/container'
	import type { Component } from 'vue'
	export const services: ServiceConfigurator = (app) => [
	[app.app, {
	service: (
	components: ComponentDefinition[],
	plugins: PluginDefinition[],
	) => {
	plugins.forEach(([...args]) => {
	config.global.plugins.push([...args])
	})
	components.forEach(([name, component]: [string, Component]) => {
	config.global.components[name] = component
	})
	return async () => {
	throw new Error('You shouldn\'t be calling $.app during testing, just get(\'$.app\') is fine')
	}
	},
	arguments: [
	app.components,
	app.plugins,
	],
	}],
	[app.htmlVars, {
	service: () => htmlVars,
	}],
	]

Which is currently in the application (@kumahq/kuma-gui) instead of in its own module.

We feel that the majority of this is very vue specific and therefore be moved to a test-support.ts or equivalant file under app/vue. That way when we make app/vueinto say@kumahq/vue-container` this code will then be in its own module. Note we don't need to make the module yet, jus move the file around.

Lastly, there is a htmlVars injection in that same file, ideally this belongs in app/kuma as its about kuma. At first glance to me this could probably go in a app/kuma/test-support.ts, but I could be wrong on that one.

[github-actions]

This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant, please comment on it or attend the next triage meeting.

[johncowen]

This was to work towards splitting the kuma application up into other reusable modules so we don't have to depend on kuma the application and instead could depend on the modules. But this one is very kuma-oriented and not very generic, so probably not worth doing.