Is your feature request related to a problem? Please describe.
Currently, when running confluence children <id>, the command only returns child pages. However, Confluence also supports folders, and these are not included in the response. This makes it difficult to accurately represent and manage existing Confluence hierarchies that contain both pages and folders.
Describe the solution you'd like
It would be helpful if the command could also return child folders in addition to child pages. This would allow consumers of the CLI to fully discover and traverse the content hierarchy of a Confluence space.
Describe alternatives you've considered
As a workaround, I currently create placeholder pages instead of folders to preserve the local directory structure. While functional, this approach adds unnecessary pages and does not reflect the actual Confluence structure. I would prefer using native Confluence folders directly.
Use case
We maintain documentation in multiple repositories with well-defined folder structures. Our goal is to mirror this documentation to Confluence through an automated CI/CD pipeline, as Confluence serves as the company's central source of truth and is more accessible for many users than the underlying repositories.
To accurately replicate the repository structure in Confluence, the pipeline needs visibility into both pages and folders. Without folder support, maintaining a consistent hierarchy becomes unnecessarily complicated.
Additional context
N/A
Implementation suggestions
Possible approaches:
- Include folders in the default response of
confluence children <id>.
- Introduce an optional flag (for example,
--type pages|folders|all) that allows users to choose whether they want pages, folders, or both returned.
- Alternatively, provide a dedicated option to include folders alongside pages while maintaining backward compatibility.
Is your feature request related to a problem? Please describe.
Currently, when running
confluence children <id>, the command only returns child pages. However, Confluence also supports folders, and these are not included in the response. This makes it difficult to accurately represent and manage existing Confluence hierarchies that contain both pages and folders.Describe the solution you'd like
It would be helpful if the command could also return child folders in addition to child pages. This would allow consumers of the CLI to fully discover and traverse the content hierarchy of a Confluence space.
Describe alternatives you've considered
As a workaround, I currently create placeholder pages instead of folders to preserve the local directory structure. While functional, this approach adds unnecessary pages and does not reflect the actual Confluence structure. I would prefer using native Confluence folders directly.
Use case
We maintain documentation in multiple repositories with well-defined folder structures. Our goal is to mirror this documentation to Confluence through an automated CI/CD pipeline, as Confluence serves as the company's central source of truth and is more accessible for many users than the underlying repositories.
To accurately replicate the repository structure in Confluence, the pipeline needs visibility into both pages and folders. Without folder support, maintaining a consistent hierarchy becomes unnecessarily complicated.
Additional context
N/A
Implementation suggestions
Possible approaches:
confluence children <id>.--type pages|folders|all) that allows users to choose whether they want pages, folders, or both returned.