feat: support semantic-release higher than version 19

[g-ongenae]

Fix #176.

Tested on @algoan/pubsub for publishing v6:

• npm: @algoan/pubsub
• github: @algoan/pubsub

[jackmoxley]

Isn't removing the reload going to mean we are using the same semantic-release/npm each time?

[g-ongenae]

@jackmoxley, That depends on how await import behaves, so I don't know for sure. If you have a way to test that, I'll gladly take a look into it.

[jhnns]

@g-ongenae Unfortunately await import is going to re-use the cached module entry. Node.js doesn't expose the internal module cache like require.cache.

@amanda-mitchell do you have any plans to make this work with ECMAScript modules? I've tried a solution with Worker threads (because each thread gets its own module cache), but that doesn't work because of function arguments that can't be cloned (probably context).

The safest solution I can think of is to actually copy the whole @semantic-release/npm folder to a temporary folder for each registry. Not very elegant, but it would probably work.

[amanda-mitchell]

I’ve been reading up on the internals of how node handles es modules, and I think that the cache can be deliberately suppressed by including a unique query string on each import.

I’ll try to find some time to play around with this soon.

[jhnns]

Oh wow, that is clever.

I think that's going to work for a single ES module. The problem is that you can only add a query string to your import, but not the following internal imports.

A possible solution could be to bundle the whole package in a single file upon install.

[jhnns]

Alternatively we could ask the maintainers of semantic-release to remove the state on module level (or send a PR). It's probably also more testable this way.

[amanda-mitchell]

I think that's going to work for a single ES module. The problem is that you can only add a query string to your import, but not the following internal imports.

True! I have not yet looked into where the module level state is stored in the latest version of the module: this will only work if it’s at the top.

Alternatively we could ask the maintainers of semantic-release to remove the state on module level (or send a PR)

That’s certainly the most attractive option! …although I also wouldn’t hold my breath for it, given the “you shouldn’t do that” response to the issue you opened.

[amanda-mitchell]

Update: I took a quick peek through semantic-release/npm this morning, and in the current code, it looks like the only module-level state is the name of a temp file that is created in the root module.

Knowing this, it should be able to orchestrate something that works for the current version.

[amanda-mitchell]

@jackmoxley, @jhnns, @g-ongenae, after significant struggle, I got all of it working in a fresh branch.

Thanks for the nudge to fix this!

[jhnns]

Awesome, thank you ❤️

I also noticed that they only have this temp filename on the module level. My only concern is that they will introduce state again as they don't know of our use case... but let's see.