Skip to content

Conversation

@Zih0
Copy link
Collaborator

@Zih0 Zih0 commented Jan 23, 2026

Changes

Fix JSDoc parser to correctly handle deeply nested parameter properties (3+ levels)

Example

/**
 * @param {Object} config - Configuration object
 * @param {Object} config.database - Database settings
 * @param {Object} config.database.connection - Connection settings
 * @param {string} config.database.connection.host - Database host
 * @param {number} config.database.connection.port - Database port
 * @param {string} config.database.name - Database name
 */

AS-IS

config.database.connection.host → config.nested[database.connection.host]
SCR-20260123-lchy

TO-BE

config.database.connection.host → config.nested[database].nested[connection].nested[host]
SCR-20260123-ldui

@vercel
Copy link

vercel bot commented Jan 23, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Review Updated (UTC)
docflow-docs Ready Ready Preview, Comment Jan 27, 2026 8:28am

Request Review

@Zih0 Zih0 self-assigned this Jan 23, 2026
expect(result.parameters?.[0].nested?.[2].defaultValue).toBe("true");
});

it("should parse deeply nested parameter properties (3+ levels)", () => {

Choose a reason for hiding this comment

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

I think we should add some test cases for edge cases like this to improve robustness. For example, what happens if the parent is declared after its children?

/**
 * @param {Object} config.database.connection - Connection settings
 * @param {string} config.database.connection.host - Database host
 * @param {number} config.database.connection.port - Database port
 * @param {string} config.database.name - Database name
 * @param {Object} config.database - Database settings
 * @param {Object} config - Configuration object
 */
export function configure(config: any): void {
  // implementation
}

Copy link
Collaborator Author

@Zih0 Zih0 Jan 26, 2026

Choose a reason for hiding this comment

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

I added test cases.
cf3e539
a3d58cd

Comment on lines 163 to 201
private insertParamAtPath({ into, path, param }: {
into: ParameterData[];
path: string[];
param: ParameterData;
}): void {
const [currentSegment, ...remainingPath] = path;
if (currentSegment == null) {
return;
}

if (isEmpty(remainingPath)) {
into.push({ ...param, name: currentSegment, nested: [] });

return;
}

const existingChild = into.find((n) => n.name === currentSegment);
const child = existingChild ?? this.createPlaceholderObjectParam(currentSegment);
if (existingChild == null) {
into.push(child);
}

const nestedParam = { ...param, name: parts.slice(1).join(".") };
parent.nested = parent.nested || [];
parent.nested.push(nestedParam);
this.insertParamAtPath({
into: child.nested ?? [],
path: remainingPath,
param,
});
}

private createPlaceholderObjectParam(name: string): ParameterData {
return {
name,
type: "Object",
description: "",
required: true,
defaultValue: undefined,
nested: [],
};
}

Choose a reason for hiding this comment

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

I'm not sure this is the optimal way to write this method — it relies heavily on imperative code with mutations rather than declarative code that returns values. Also, looking at this call in isolation, it's hard to tell what the method actually does without seeing the implementation:

// Can we understand what this method does without the surrounding context?
this.insertParamAtPath({
  into: child.nested ?? [],
  path: remainingPath,
  param,
});

I think we can rewrite this to return a value instead, making it more declarative and predictable. Let me think about this for a moment.

Copy link
Collaborator Author

@Zih0 Zih0 Jan 26, 2026

Choose a reason for hiding this comment

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

I refactored some mutable logic to make it more immutable, but please let me know if you see any issues.

e7ae3ad
5931920

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.

3 participants