Just a nitpick, but why check against null?
I would expect:

const isNode = typeof process !== 'undefined' && process.versions && process.versions.node

Good call. I should have seen this.

I wonder whether there is a better way to do this...

There is a field in package.json called browser that might be better suited for this use case.
The way it works is this: You specify which file(s) to use instead of the default one(s), when running on the browser.
For example, we could make a new file called core-appenders.js and place the lines creating the coreAppenders map and populating it with the core appenders in that file. We could then make a second file called core-appenders-browser.js and place the equivalent code for the browser in that file. Then, in package.json we would write:

{
  "browser": {
    "./lib/appenders/core-appenders.js": "./lib/appenders/core-appenders-browser.js"
  }
}

Then, Browserify, Webpack and Rollup et all will know to replace the code in core-appenders.js with the code in core-appenders-browser.js when building the browser version.

An example where this is used is the popular logging package debug:
https://github.com/visionmedia/debug/blob/4.2.0/package.json#L55

There are two forms for the browser field:

• Object with node file names as keys and browser filenames as values
• File name of entry point to use instead of the one listed in the main field.

I hadn't realised this - nicely spotted, and clearly explained! Only thing that comes to mind is a possible ordering issue, or that there would be code duplication and one of those files (node or browser) could get left behind. I'm not sure i that's a higher price or the runtime cost; given the runtime cost is (as far as I can see) once off, I think it might be better to leave it as-is. More thought required!

An important thing to understand about this line of code:

coreAppenders.set('file', isNode ? require('./file') : {});

Even though the isNode check will prevent the file appender from being added to the coreAppenders map on the browser, it actually still gets bundled into the browser bundle. The reason is that, even though Webpack is pretty clever, it's not actually smart enough to figure out that isNode will always be false on browsers. Basically what Webpack does is find all required files in a static analysis phase and make sure each and every single file that might be required at runtime gets packaged into the bundle.

Using the browser field to inform Webpack and other bundlers about the fact that the file appender is not used on browsers is the accepted/standard way to do this.

there would be code duplication

That depends entirely on how you structure things. Make sure you place only the code that differs between Node and browsers in separate files and then use the browser field to map the browser versions of those files. No code needs to be duplicated.