Support *.cjs configs

[opiation]

New feature motivation

When attempting to use semantic-release with a ESM-written package ("type": "module") and node with ES modules enabled, a plain release.config.js config fails understandably given the tool is written with require()s. Renaming the config to release.config.cjs does not work as the version of cosmicconfig used by semantic-release does not search for .cjs files. Thus, only the json config options are available.

Updating the cosmicconfig dependency to v7.0.0 would allow one to use semantic-release developing a package implicitly in ES modules (--experimental-modules).

New feature description

Supports *.cjs file extensions like release.config.cjs for configuring semantic-release.

New feature implementation

Update cosmicconfig dependency to v7.0.0 which adds support for *.cjs file extensions.

[travi]

please double check the version of semantic-release that you are using. the current version of cosmiconfic that is depended on by semantic-release is already v7.0.0:

semantic-release/package.json

Line 29 in 6013a56

"cosmiconfig": "^7.0.0",

[opiation]

My apologies, @travi. I could have sworn that I looked at master but must have still been looking at the v17.3.0 tag. You're correct that cosmicconfig was indeed updated recently (v17.3.6). I've updated my local version to use v17.3.9 however, .cjs still is not read.

My config:

// release.config.cjs

const releaseRules = [
  { type: 'docs', release: 'patch' }
]

const gitOptions = {
  assets: ['CHANGELOG.md', 'dist/**/*', 'package.json']
}

module.exports = {
  plugins: [
    ['@semantic-release/commit-analyzer', { releaseRules }],
    '@semantic-release/release-notes-generator',
    '@semantic-release/changelog',
    '@semantic-release/npm',
    ['@semantic-release/git', gitOptions]
  ]
}

$ yarn run semantic-release --debug --dry-run

[11:22:25 AM] [semantic-release] › ℹ  Running semantic-release version 17.3.9                                                                                                                  
  semantic-release:config load config from: undefined +0ms 

^^^ I've omitted the remainder of the output as the undefined config seems sufficient to indicate this might be a bug. Given that possibility, I'll include some more details to save time.

$ node --version
v14.15.4

$ echo ${NODE_OPTIONS}
--experimental-modules --experimental-vm-modules --max-old-space-size=4096

$ yarn --version
1.22.10

Using Ubuntu 18.04.5 LTS

Let me know if any additional information is needed or if I've misread any documentation about using cjs configs.

EDIT: Also tried clearing node_modules and reinstalling to no avail.

$ rm -rf node_modules && yarn install

[travi]

this seems like a valid request and we want to make sure that semantic-release isn't blocking this capability. however, we may not get a chance to investigate deeply right away.

if you could help us investigate, it would really help this be resolved more quickly. our usage of cosmiconfig is here:

semantic-release/lib/get-config.js

Line 24 in 21c151f

const {config, filepath} = (await cosmiconfig(CONFIG_NAME, {searchPlaces: CONFIG_FILES}).search(cwd)) || {};

. if you identify a problem with our usage, please start a PR suggesting the change that would fix our usage and we'll be happy to work through additional details there.

[opiation]

Sure thing! Here's what I've found briefly so far...

In lib/get-config.js, cosmicconfig() is invoked with CONFIG_NAME as the moduleName (from the cosmicconfig API) and CONFIG_FILES is provided as explicit searchPlaces.

semantic-release/lib/get-config.js

Line 11 in f25c352

const CONFIG_NAME = 'release';

semantic-release/lib/get-config.js

Lines 12 to 20 in f25c352

	const CONFIG_FILES = [
	'package.json',
	`.${CONFIG_NAME}rc`,
	`.${CONFIG_NAME}rc.json`,
	`.${CONFIG_NAME}rc.yaml`,
	`.${CONFIG_NAME}rc.yml`,
	`.${CONFIG_NAME}rc.js`,
	`${CONFIG_NAME}.config.js`,
	];

According to the cosmicconfig docs however, the module name, in this case "release" is used to create the default set of search places.

This is used to create the default searchPlaces and packageProp.

By providing the searchPlaces explicitly with CONFIG_FILES, these defaults are overwritten, thus excluding the .cjs variants that are now supported by cosmicconfig.

For reference, the default searchPlaces can be found here (inlined below).

[
  'package.json',
  `.${moduleName}rc`,
  `.${moduleName}rc.json`,
  `.${moduleName}rc.yaml`,
  `.${moduleName}rc.yml`,
  `.${moduleName}rc.js`,
  `.${moduleName}rc.cjs`,
  `${moduleName}.config.js`,
  `${moduleName}.config.cjs`,
]

Based on the current implementation and the defaults generated by cosmicconfig, it seems likely the best course of action is to remove the explicit searchPlaces option and rely on cosmicconfig's defaults which would include .cjs variants.

I might have time to test this locally and/or submit a PR but thought I'd at least share these findings here in case anyone has time to do so.

[opiation]

I was able to test this locally in the end and removing the searchPlaces works as I expected and described above. I'll submit a PR shortly.

[opiation]

To anyone interested, submitted PR #1815 and it is pending review.