Investigate if .cjs extension support is needed.

[phated]

From #59, we believed that .cjs extension support was needed, but I think that was due to not properly supporting the ESM syntax. With the work done in gulp-cli by @snoak, we can import ESM modules.

Given that, I only added support for .mjs in #65 and I wanted to open this to investigate if we actually need to support the .cjs extension.

If we end up needing to support it, I've put in place the architecture to support & test the extension on all versions of node.

[snoack]

Node.js considers a script an ES module if it either has the file extension .mjs, or if it has the file extension .js and is located in a package that declares "type": "module" in its package.json.

Node.js considers a script a CommonJS module if it either has the file extension .cjs, or if it has the file extension .js and is not located in a package that declares "type": "module" in its package.json.

So if a package uses "type": "module" but for whatever reason sticks to CommonJS for their Gulpfile that file would have to be named gulpfile.cjs.

[phated]

Thanks for the additional details! That should help us make a decision.

but for whatever reason sticks to CommonJS for their Gulpfile

My assumption was that we didn't support ESM with "type": "module", so they needed to keep their gulpfile in CommonJS. If that's the only reason, I don't see a need to support the .cjs extension. However, I'll keep this open to see if someone has a use-case for it with the new ESM support.

[snoack]

I don't think this is true. We call require() first and if it fails with ERR_REQUIRE_ESM we fallback to import().

So if there is a gulpfile.js in a package that declares "type": "module", require() will fail because it considers it an ES module which cannot be loaded that way, but import import() should succeed if the script uses valid ESM semantics.

However, if there is a gulpfile.js using CommonJS semantics in a package that declares "type": "module", require() will fail because it considers it an ES module which cannot be loaded that way, then import() will fail when the script attempts to access require, exports or module.exports which don't exist in ES modules.

[anshumanv]

Hey 👋

Thanks for the support for .mjs config, over at webpack-cli we use interpret to use various formats of webpack config files as per the extensions supplied by interpret, is it possible to add .cjs to the extension list?

[phated]

@anshumanv Can you explain a little more? node.js supports "fall through" when requiring files that don't have an extension registered, so wouldn't .cjs just be loaded normally as a .js file?

[anshumanv]

Hey @phated yes, so we use interpret to get webpack configs with valid extension whether .ts, .js etc so whatever configs are supplied via --config flag to the cli, we check if they have a valid extension from interpret - https://github.com/webpack/webpack-cli/blob/a380a785c296208af7017f547cd34cf72517f9da/packages/webpack-cli/lib/groups/ConfigGroup.js#L46 and filter out the ones which are not, so since .cjs is not listed in the extension list, it's not recognized as a valid config. Is there any other approach that I can take? To me simple solution seems to list it in the extensions list.

[phated]

Oh, that's much different than the way gulp uses list library. We use the rechoir library to prepare the environment with the loaders and I believe it allows any unknown extension to fallthrough to the default node loader.

[anshumanv]

Ah okay, I think it makes a lot of sense to fallback to default node loader. I've opted for the same approach 👍 Thanks @phated 💯