feat: cjs support in custom middleware file names

[valoricDe]

With the new field "type": "module", in package.json node js might require different file names.

Therefore I added logic that it also handles .cjs and .mjs files

[valoricDe]

@olegdovger Hi, this is currently blocking us. Would you be able to support here and review this small PR?

[valoricDe]

@Daanoz or @valeriiudodov are you able to help here?

[muratcorlu]

Hello. Thanks for your contribution! I realized that I'm not running tests on pipelines. While I adding tests to PR actions, can you add test cases and test on your local (by running npm test)

[riverrun-git]

@muratcorlu Insisting on additional test cases here is difficult. You would have to duplicate every GET.js, , POST.js, etc. with almost identical files named GET.cjs, GET.mjs, POST.cjs, POST.mjs, etc... Then run the tests in an environment setup to require CJS files to be named *.cjs, then in one where MJS files need to be named *.mjs and then in one where files need to be named *.js.
How to achieve that in a test pipeline is unclear.
This is going to be a blocker for us soon.
Could you not review the (trivial) changes instead?

[muratcorlu]

I just tried to write test and realized that, if you write the custom middleware in ESM format like below, current implementation doesn't work, since the library is in commonjs format and we can not just "require" an mjs file.

export default function (req, res) {
  res.json({
    result: 'mjs works'
  });
}

I get error:

SyntaxError: Unexpected token 'export'

So now I'm curious if you managed to run this in your -manual- test? Do you compile mjs files to commonjs before using with connect-api-mocker?

[valoricDe]

I moved everything to cjs because of this reason

[muratcorlu]

Would it be acceptable to modify this pull request to exclusively support CommonJS and eliminate support for .mjs files, enabling us to proceed with the merge?

Regarding .mjs, we could contemplate transitioning this library to ECMAScript Modules (ESM) to facilitate support for both module systems. This approach is preferable because importing CommonJS files into ESM modules is straightforward, whereas importing .mjs files into CommonJS requires additional effort. Besides, ESM represents the future direction of JavaScript module systems.

[valoricDe]

Suggested change

	const fileExtensions = [methodFileExtension, 'mjs', 'cjs', 'js']
	const fileExtensions = [methodFileExtension, 'cjs', 'js']

[valoricDe]

Suggested change

	return !!str.match(/\.(c|m)?js$/)
	return !!str.match(/\.c?js$/)

[valoricDe]

Feel free to commit my suggestions

[github-actions]

🎉 This PR is included in version 1.11.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀