Supported configuration file extension check does not use the per-generator default

[haykam821]

The setPagesConfig function uses different error messages depending on whether the generator configuration file has a correct extension. However, the configuration file used for this check is based on the context generator_config_file input only, rather than the default configuration file for the generator used that is computed by the getConfigParserSettings function.

As a result, if generator_config_file is not specified, then errors within the setPagesConfig function will always be blamed on an incorrect file extension.

[janbrasna]

Basically the check:

configure-pages/src/set-pages-config.js

Lines 80 to 90 in b490f53

	} catch (error) {
	const isSupportedFileExtension = SUPPORTED_FILE_EXTENSIONS.some(ext => generatorConfigFile.endsWith(ext))
	// Logging
	if (!isSupportedFileExtension) {
	core.warning(
	`Unsupported configuration file extension. Currently supported extensions: ${SUPPORTED_FILE_EXTENSIONS.map(
	ext => JSON.stringify(ext)
	).join(', ')}`,
	error
	)

should return isSupportedFileExtension true if !generatorConfigFile and that's all I guess.

(It would be better to use settings.configurationFile output instead that should have the template config path filled in if no passed config, but that's another scope and the actual getter might have thrown so no point getting the output again, oh well…)

So maybe just something like:

--- a/src/set-pages-config.js
+++ b/src/set-pages-config.js
@@ -76,12 +78,12 @@ function setPagesConfig({ staticSiteGenerator, generatorConfigFile, siteUrl }) {
     const settings = getConfigParserSettings({ staticSiteGenerator, generatorConfigFile, siteUrl })
     new ConfigParser(settings).injectAll()
   } catch (error) {
-    const isSupportedFileExtension = SUPPORTED_FILE_EXTENSIONS.some(ext => generatorConfigFile.endsWith(ext))
+    const isSupportedFileExtension = !generatorConfigFile || SUPPORTED_FILE_EXTENSIONS.some(ext => generatorConfigFile.endsWith(ext))
 
     // Logging
     if (!isSupportedFileExtension) {

[JamesMGreene]

I believe the main problem here (our failure to log the actual error message) is resolved by:

• Convert errors into Actions-compatible logging with annotations #138

As for failure to correctly detect config files, I'm going to leave that in another issue:

• Doesn't recognize next.config.mjs #107

[janbrasna]

@JamesMGreene Thanks for keeping this in mind. The issue here is different than the referenced autodetection. To quote the important bit:

" if generator_config_file is not specified, then errors within the setPagesConfig function will always be blamed on an incorrect file extension."

To simplify, if you don't pass any config file and the action uses its own implicit boilerplate, the conditional logic testing whether to log "We were unable to determine…" or "Unsupported configuration file extension…" fails because

configure-pages/src/set-pages-config.js

Line 85 in fc47e3c

const isSupportedFileExtension = SUPPORTED_FILE_EXTENSIONS.some(ext => generatorConfigFile.endsWith(ext))

this doesn't work for when there's no config specified, as generatorConfigFile.endsWith(ext) is empty/falsy, so it "seems" that all errors are then blamed on extension, when that isn't the case if you're not providing a config at all;)

It's just cosmetics though.

[JamesMGreene]

Ah, sorry, thanks for persevering on explaining this one! 😅 I see what you mean now. 👌

[janbrasna]

No worries;) I'd have already demonstrated it better by proposing a fix just by adding the const isSupportedFileExtension = !generatorConfigFile || SUPPORTED_FILE_EXTENSIONS.some… to avoid blaming any errors without config file present on its extension straight away, however TBH I lack the imagination to properly test such change esp. in edge case error handler and not to introduce any potential surface for more issues stemming from it so I leave that to others… I see you've taken more systematic approach to the whole configs magic so I'm just watching from the passenger seat: Good job! 🎩

[JamesMGreene]

A fix for this is now included in actions/configure-pages@v5. 🚀