Convenience logging API for extensions?

[fmuellner (Florian Müllner)]

Following this post, I have been pondering a convenience API for extension logging.

My initial thoughts are along those lines:

import {Extension} from 'resource:///org/gnome/shell/extensions/extension.js';

export let console = null;

export default class ConsoleTestExtension extends Extension {
    constructor(metadata) {
        super(metadata);
        
        console = this.getLogger();
    }
    
    enable() {
        console.log('enabled');
    }

    disable() {
        console.log('disabled');
    }
}

That would result in log output as below:

GNOME Shell-Message: 01:49:55.395: [Console test] enabled
GNOME Shell-Message: 01:50:00.862: [Console test] disabled

The following would be even more convenient (but also more ineffective, so I’m a bit reluctant):

import {Extension, console} from 'resource:///org/gnome/shell/extensions/extension.js';

Is there an interest in such an API?

[jrahmatzadeh (Javad Rahmatzadeh)]

We have some extensions creating their own custom logging function or class to have the extension name in the log message. For example, Desktop Cube and Blur my Shell.

Creating the logger instance in the entry point can be trying for most extensions. Especially the large ones since they need to pass the logger instance to other classes.

Does the second one seem buggy if they use it in global scope or the entry point constructor?

[fmuellner (Florian Müllner)]

@jrahmatzadeh

Creating the logger instance in the entry point can be trying for most extensions. Especially the large ones since they need to pass the logger instance to other classes.

My idea is to do

export let console = null;

in the main extension file, so other modules can import it with

import {console} from './extension.js';

That is, for other modules the only difference between the two options is from where they import the (alternative) console object.

@jrahmatzadeh

Does the second one seem buggy if they use it in global scope or the entry point constructor?

Yes. Anything that needs to access the extension object in any form cannot work at the global scope.

The first option will at least work in the entry point constructor, once the assignment has been made.

An imperfect workaround (with the first option) is to use

export let console = globalThis.console;

export default class ConsoleTestExtension extends Extension {
    constructor(metadata) {
        super(metadata);
        
        console = this.getLogger();
    }
}

That way the custom console object is always set, but early logging happens through the “normal” console object.

[jrahmatzadeh (Javad Rahmatzadeh)]

Since we don’t let extensions create instances of objects in the entry point constructor, both of them should have the same result.

I’m more into the getLogger() approach since the developers know that needs to be called to have the logger instance.