refactor(esm): converted the package to esm

[travi]

BREAKING CHANGE: @semantic-release/commit-analyzer is now a native ES Module. It has named exports
for each plugin hook (analyzeCommits)

fixes #296

[travi]

i've spent more time that i'd like to admit trying to understand several instances of this error:

 Error {
    code: 'ERR_REQUIRE_ESM',
    message: `require() of ES Module /Users/path/to/semantic-release/commit-analyzer/test/fixtures/release-rules.js from /Users/path/to/semantic-release/commit-analyzer/noop.js not supported.␊
    Instead change the require of release-rules.js in /Users/path/to/semantic-release/commit-analyzer/noop.js to a dynamic import() which is available in all CommonJS modules.`,
  }

and where noop.js was even coming from. in the end, i think it is related to sindresorhus/import-from#9 and

commit-analyzer/lib/load-release-rules.js

Line 24 in 7c693d9

? importFrom.silent(__dirname, releaseRules) || importFrom(cwd, releaseRules)

we may need to consider an alternative approach with this. any thoughts come to mind @gr2m?

[gr2m]

Not out of hand, I don't think I used importFrom in any other ESM project. Maybe we can use another approach that doesn't need import-from?

[travi]

Maybe we can use another approach that doesn't need import-from?

yeah, i think thats what i'm looking for ideas around. i havent thought too far about it yet, but i think we may need to come up with alternative ideas for this piece.

[dgilperez]

May I ask for status of this? I just switched an App to ESM and I found semantic-release is not working, which probably depends on this PR to be merged (among others). Since I have this thing fresh, I may add some value to any roadblock, if you can provide some status for me.

[travi]

I just switched an App to ESM and I found semantic-release is not working, which probably depends on this PR to be merged

semantic-release runs as its own executable, so the type of your project should have no impact on how semantic-release executes. if you have a .releaserc.js to configure semantic-release, that is the one exception and you may need to convert that file to match your project.

[dgilperez]

Thanks a lot! I managed to have it working by setting the releaserc.js file properly - thanks! El lun., 6 jun. 2022 21:03, Matt Travi ***@***.***> escribió:

…

I just switched an App to ESM and I found semantic-release is not working, which probably depends on this PR to be merged semantic-release runs as its own executable, so the type of your project should have no impact on how semantic-release executes. if you have a .releaserc.js to configure semantic-release, that is the one exception and you may need to convert that file to match your project. — Reply to this email directly, view it on GitHub <#297 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACATDW2A4SQGBMPUIKF37TVNZDR3ANCNFSM5KHEJC3A> . You are receiving this because you commented.Message ID: ***@***.***>

[sheerlox]

i've spent more time that i'd like to admit trying to understand several instances of this error:

 Error {
    code: 'ERR_REQUIRE_ESM',
    message: `require() of ES Module /Users/path/to/semantic-release/commit-analyzer/test/fixtures/release-rules.js from /Users/path/to/semantic-release/commit-analyzer/noop.js not supported.␊
    Instead change the require of release-rules.js in /Users/path/to/semantic-release/commit-analyzer/noop.js to a dynamic import() which is available in all CommonJS modules.`,
  }

and where noop.js was even coming from. in the end, i think it is related to sindresorhus/import-from#9 and

commit-analyzer/lib/load-release-rules.js

Line 24 in 7c693d9

? importFrom.silent(__dirname, releaseRules) || importFrom(cwd, releaseRules)

hey @travi 👋 I see the same code has been released in v11.0.0 of @semantic-release/release-notes-generator (about a month ago), so I'm wondering if this is still a blocking point, since versions of import-from are both set to ^4.0.0 and the importFrom function is used in the same exact way?

And if there's still an issue here, could that imply the same issue is present in v11 of @semantic-release/release-notes-generator?

[travi]

to be honest, i haven't had the chance to revisit the conversion of this plugin, so i'm not sure if the things that we've learned from converting other packages would apply in a way that would get us past this concern in this context.

And if there's still an issue here, could that imply the same issue is present in v11 of @semantic-release/release-notes-generator?

are you encountering a problem in the release notes generator that you think could be related to this?

[sheerlox]

are you encountering a problem in the release notes generator that you think could be related to this?

not at all! I came to this issue because I was trying to update some dependencies on my conventional-changelog preset (e.g. insurgent-lab/conventional-changelog-preset#8), then figured out that if I transitioned the preset to ESM, @semantic-release/commit-analyzer wouldn't be able to load it anymore, right?

this is not a big deal though, so I'll just monitor this PR and transition the preset to ESM when it becomes possible, no pressure 😉

[travi]

then figured out that if I transitioned the preset to ESM, @semantic-release/commit-analyzer wouldn't be able to load it anymore, right?

this is very possible, and quite honestly likely. i dont have the full picture in my head at the moment, but from brief consideration this morning, i do believe you are correct. i think we are in an ok state with release-notes-generator because existing presets have not yet converted to esm.

you are highlighting that we are at risk of breakage for folks if a preset does convert since i didnt come across the consideration that i caught above in the conversion of the release-notes-generator. i really appreciate that you dug deep enough to figure this out while considering the conversion of your preset, but especially appreciate that you reached out with the information to have a conversation with us about it.

[travi]

the other thing that i think is worth calling out as a result of this information, as it relates to moving the effort forward for this package, i think we could consider this detail to not be a blocker for converting this plugin. that choice would leave us in the situation where we would be unable to load presets that have been converted to esm, but we are already in that situation with release-notes-generator. while we may want to enable loading of esm presets, it could make sense to follow up with a separate effort for enabling that sometime after we convert this package to esm.

[sheerlox]

it's a pleasure really, been using semantic-release for more than 4 years, so many thanks to you guys for creating and maintaining this awesome set of tools!

P.S: I'd love to offer to contribute on this issue, but right now I already have a lot on my mind. I might come back to it in a while if it is still hanging 😉

[sheerlox]

it could make sense to follow up with a separate effort for enabling that sometime after we convert this package to esm.

that definitely makes sense to me!

[gr2m]

w00p it's happening dot gif