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.