Skip to content

feat: allow config file to have config globs - #129

Open
ruocco-l wants to merge 1 commit into
masterfrom
feat/config-globs
Open

feat: allow config file to have config globs#129
ruocco-l wants to merge 1 commit into
masterfrom
feat/config-globs

Conversation

@ruocco-l

Copy link
Copy Markdown
Contributor

Closes #128

  • New optional configs?: ActorGlobConfigEntry[] on the config file. Each entry has exactly one of folder/actorFullName (a glob pattern, matched via minimatch) plus whatever fields to overlay onto matching actors.
  • The merge (mergeGlobConfigs) is field-agnostic — it overlays whatever properties a matching entry carries besides its match key, with no special knowledge of tokenEnvVar or any other field name. An unrecognized/misspelled property is merged in and simply has no effect, same as today.
  • Precedence, lowest to highest: matching folder-glob entries → matching actorFullName-glob entries → the actor's own literal entry (never overridden). Within the same glob type, the last matching entry in the array wins — purely by array position, not by pattern specificity.
  • Matching follows standard minimatch glob rules, see https://github.com/isaacs/minimatch for the full pattern syntax. Notably, "match every actor" needs **, not *, since * doesn't cross path segments.
  • tokenEnvVar is optional on an actor entry now, but still required overall: once an actor's full config is resolved (literal + any matching configs), a tokenEnvVar must be present or readConfigFile throws — this is the only place the code cares about that specific field name.
  • configs is entirely optional; a config file without it behaves exactly as before.

@metalwarrior665 metalwarrior665 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This looks simpler than I thought :) I have just minor remarks, feel free to argue against them. Let's wait for Juan but this seems quite uncontroversial.

Comment thread bin/utils.ts
for (const [index, configEntry] of configs.entries()) {
const { folder, actorFullName } = configEntry as ActorGlobConfigEntry;

// TODO: Allow for combined filtering?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I would allow this, don't think it is that confusing or dangerous. You simply filter once per folder and then per name. There might be legit use-cases for this

Comment thread bin/utils.ts
import { selectActors } from './actor-filtering.js';
import { isPathWithinScope } from './path-utils.js';
import type { ActorConfig, ActorConfigFile } from './types.js';
import type { ActorConfig, ActorConfigFile, ActorConfigFileEntry, ActorGlobConfigEntry } from './types.js';

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

These types don't match very well, one says "File", other doesn't.

btw we already have ActorConfig type which is basically the same thing, we should either unify them or derive one from the other. Are there cases where these will differ? If we are simply merging them then they should not differ. No need to solve that in this PR but sooner rather than later.

Comment thread bin/utils.ts

const validateGlobConfigEntries = (configs: unknown[]): ActorGlobConfigEntry[] => {
for (const [index, configEntry] of configs.entries()) {
const { folder, actorFullName } = configEntry as ActorGlobConfigEntry;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Could be zod parse I guess but I don't know if you can get such a nice errors from it, don't have experience

Comment thread bin/utils.ts

let overlay: Partial<ActorConfigFileEntry> = {};
for (const configEntry of [...matchingFolderConfigs, ...matchingActorFullNameConfigs]) {
const { folder: matchedFolder, actorFullName: matchedActorFullName, ...rest } = configEntry;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Let's think a bit if we shouldn't separate the matching fields folder, actorFullName vs the configs, it is a bit weird they are on the same level

Comment thread bin/utils.ts
);

let overlay: Partial<ActorConfigFileEntry> = {};
for (const configEntry of [...matchingFolderConfigs, ...matchingActorFullNameConfigs]) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

If we want to support having both folder and name with AND logic, this would need to change

Comment thread bin/utils.ts
const matchingActorFullNameConfigs = configs.filter(
(configEntry) =>
configEntry.actorFullName !== undefined &&
typeof actorEntry.actorFullName === 'string' &&

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We already validate this eariler and the type should be string | undefined now, no?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Create globs for config file

3 participants