Investigate the baseUrl resolving process as a whole

[ang-zeyu]

Is your request related to a problem?

#1026 (comment)

Removing _rebaseReferenceForStaticIncludes which is used on static <includes> during the preprocess stage seems to have no effect on the generated output.

Inspecting said code and _rebaseReference in the main parser, it seems both functions do the same thing, in that it renders {{baseUrl}} according to the location ( site ) that the included file is in.

Describe the solution you'd like
Let's investigate whether we could unify the baseUrl resolving process to either the preprocess stage, or resolveBaseUrl only, which should make for better code readability and maintainability.

[acjh]

seems to have no effect on the generated output.

Did you test with nus-cs2103/website-base?

[ang-zeyu]

Did you test with nus-cs2103/website-base?

Yup, tested

_rebaseReferenceForStaticIncludes also used pageData.includes('{{baseUrl}}') as a guard clause, which would have missed something like {{ baseUrl }}/...

_rebaseReference essentially does the same thing as _rebaseReferenceForStaticIncludes, which is resolving baseUrl based on the included file's location ( or 'supposed' location in the case of boilerplates ), although it has a few quirks of its own #1087

[acjh]

Did you find the PR that introduced _rebaseReferenceForStaticIncludes and check whether the use case is still relevant?

[ang-zeyu]

Did you find the PR that introduced _rebaseReferenceForStaticIncludes and check whether the use case is still relevant?

Found the links, will take a deeper look, though I suspect the likely cause is that changes to resolveBaseUrl + _rebaseReference fixed it inadvertedly somewhere along the way
#115 #94

[ang-zeyu]

I went back to before this method was introduced and produced a failing example, and fast forwarded to the present ( with this method removed ) to reconfirm that this is fixed.

The likely root cause was fixed in #263 ( introduced 4 months after ), which caused the relative baseUrl to be resolved according to the included source file's location rather than cwf.

It shouldn't matter whether there is a hash, because the only differerence is the retrieved content.
ie. for hash includes, we reparse the content and then use cheerio to select the segment. Otherwise, we use the entire content. This should have no effect on baseUrl resolving.

The reason _rebaseReferenceForStaticIncludes worked was that it did baseUrl resolving the right way ( ie. similar to #263 - resolving according to included source file's location ), but was only introduced for content for hashes, which later required #263 to fix in whole. #263 then made _rebaseReferenceForStaticIncludes redundant, as it is applied for both content with / without hashes.

[acjh]

Nice. Thanks for the investigation and explanation!