fix: make wiki path prefix configurable based on apiPath

[saggl]

Derives the /wiki URL prefix from apiPath instead of hardcoding it, fixing broken links on Server/Data Center instances.

🤖 Generated with Claude Code

[pchuri]

Thanks for the contribution, @saggl! This is a solid fix for Server/Data Center instances that don't use the /wiki prefix. The approach of deriving the prefix from apiPath makes sense.

One concern I noticed: there's a logic duplication between bin/confluence.js and ConfluenceClient that could lead to inconsistent behavior.

bin/confluence.js:11 uses the raw config.apiPath:

const getWebUrlPrefix = (apiPath) => apiPath && apiPath.startsWith('/wiki/') ? '/wiki' : '';

lib/confluence-client.js:38 uses the sanitized this.apiPath:

this.webUrlPrefix = this.apiPath.startsWith('/wiki/') ? '/wiki' : '';

Since sanitizeApiPath() normalizes the leading slash (e.g. wiki/rest/api → /wiki/rest/api), the two functions can produce different results for the same input. For example, if a user configures apiPath: 'wiki/rest/api' (missing leading slash):

• bin/confluence.js → '' (raw value doesn't start with /wiki/)
• ConfluenceClient → '/wiki' (sanitized value starts with /wiki/)

Suggestion: Instead of maintaining a separate getWebUrlPrefix function in bin/confluence.js, could we reuse client.webUrlPrefix from the ConfluenceClient instance? That way there's a single source of truth and the sanitization logic is always applied consistently.

The tests look good — nice coverage of Cloud, Server, and default cases. It would also be great to add a test for the edge case above (missing leading slash in apiPath).

[saggl]

Thanks for the thorough review! I've addressed the feedback:

Changes Made

✅ Removed duplicate logic - Deleted getWebUrlPrefix() and buildPageUrl() functions from bin/confluence.js

✅ Single source of truth - All URL construction now uses client.webUrlPrefix and client.buildUrl() from the ConfluenceClient instance

✅ Added edge case test - New test verifies that webUrlPrefix is correctly set to /wiki when apiPath is configured as 'wiki/rest/api/' (missing leading slash)

Benefits

• Consistent behavior: The sanitized apiPath is always used, preventing the discrepancy you identified
• Reduced code duplication: 6 lines of duplicate logic removed
• Better test coverage: Edge case is now explicitly tested

All 158 tests pass ✅

The changes ensure that users get consistent URL output regardless of whether they configure apiPath with or without a leading slash.

[pchuri]

Great work on the update, @saggl! All feedback has been addressed cleanly:

• Duplicate buildPageUrl() / getWebUrlPrefix() removed — single source of truth via client.webUrlPrefix and client.buildUrl()
• printTree signature updated consistently
• Edge case test for missing leading slash added

Code looks clean and the approach is solid. LGTM! 👍

[github-actions]

🎉 This PR is included in version 1.27.5 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀