I've put up a PR with my suggestions. Hopefully the change is agreeable.

Please let me know if anyone has any feedback and I'll try to respond quickly.

Using string includes on the name is not reliable. Something like a boolean that flags a node as being a custom image save node would be appropriate. But before all that, may I ask what the actual use-case is, for this?

Hmmm, the Node name for S&R is a legacy feature that we have not touched since the inception of this project. We might want to reconsider how to implement it. For now to unblock your node, can you just add your node's name(id) to the matching list?

Maybe something like:

const SAVE_NODES_SUPPORTED = [
  'SaveImage',
  'SaveAnimatedWEBP',
  // Custom save nodes
  'CustomSaveImage',
  ...
]

if (SAVE_NODES_SUPPORTED.includes(nodeData.name) {...}

Using string includes on the name is not reliable. Something like a boolean that flags a node as being a custom image save node would be appropriate. But before all that, may I ask what the actual use-case is, for this?

Originally posted by @webfiltered in #2218 (comment)

Being unreliable is a consideration I did have, however I feel it is reasonable to simply check that the extension we're working with is available before we do anything should be sufficient until this feature is relooked at in the future.

It's not a shining brilliance in terms of a code change, but it is small and relatively unintrusive.

As for the use case; To me it is twofold. I'll provide some example images here as well.

To have an external node input to a SaveImage node, like so;

This is useful because with long file names, and subdirectories, it can be challenging to edit them...

The second use case is for external nodes, such as this very nice node; which exports all images in a batch to a gridded output.

Under normal circumstances, without a custom implementation using a dirty flag for DateTime.Now, a custom node cannot search and replace the DateTime string.

Hmmm, the Node name for S&R is a legacy feature that we have not touched since the inception of this project. We might want to reconsider how to implement it. For now to unblock your node, can you just add your node's name(id) to the matching list?

Originally posted by @huchenlei in #2218 (comment)

I did very much figure this was a legacy feature, and as such I didn't want to go overboard with suggesting some total overhauls. I absolutely get that there are better ways to do this, but I figure a light touch here might be the best approach until something more comprehensive and maintainable can be implemented in the future.

Your solution is basically what I've set up already. I just have a stash with some private changes and this is one of them.

I thought I would share my current override since I have found it useful in my workflows so far.

For a custom node, all you should need to do is add the relevant part of saveImageExtraOutput.ts into a js file in your extension's registered WEB dir.

app.registerExtension({
  name: 'Custom.SaveImageExtraOutput',
  async beforeRegisterNodeDef(nodeType, nodeData, app) {
    if (nodeData.name === 'CustomSaveImage') {
      const { onNodeCreated } = nodeType.prototype
      nodeType.prototype.onNodeCreated = function () {
        const r = onNodeCreated
          ? onNodeCreated.apply(this, arguments)
          : undefined

        const widget = this.widgets.find((w) => w.name === 'filename_prefix')
        if (widget) widget.serializeValue = () => applyTextReplacements(app, widget.value)

        return r
      }
    }
  }
})

Disclaimer: written in GH comment box.

That is quite useful to know, actually. I appreciate that.

Although that would only apply to nodes that I write or contribute to. Perhaps that could still work as an alternative stop-gap though if you registered a custom input field to this and just loaded any widgets you want the data with using the new custom node.

That said, as I suspect this area might see some revamping soon enough, I'm loath to go too overboard here with something that might last all of a few days in the grand scheme of things.

It will apply to any node name you specify, provided it is loaded before the node definition is.