Where should extension developers put configuration settings?

JupyterLab
1

Is there a particular place where extension developers should be putting configuration settings for their extensions that cannot be overridden by the user? For example, I explored the Settings facility. overrides.json allows for default settings to be specified for extensions. However, these settings can be overridden by the user. Is there something like overrides.json where an extension can pull default settings from that cannot be overridden by the user?

I know I can create a server extension that can serve up default settings, but I am wondering if there is a canonical way of doing this.

2

The settings bundle you get back will give you the default(key: string) value for a particular key. There’s no particular way to prevent a user from setting a value to the key, as readOnly probably doesn’t work, so the user’s value would come back in .composite, but if your code doesn’t look at it…

For better build-time change detection/typing, with a bit of tsconfig.json jiggery pokery, you can get access to your raw schema, and work with it directly, but may have to unwrap things yourself, if you get fancy with $ref.

package.json
tsconfig.json # `includes`: `./schema/*.json` and `package.json`
schema/
  plugin.json
src/
  tsconfig.json  # `references`: `../`

Then you can reference the JSON in src:

import * as PKG from '../package.json';
import * as SCHEMA from '../schema/plugin.json';

and compile the mess with:

tsc -b src

You’ll get some extra tsconfig.buildinfo files, the name/location of which can also be tuned, and the json will get shipped twice to the browser, but it can be worth it… having the full JSON means you can invest time in the schema, reusing title and description (and even regular expressions) in your code, so they can’t get out of sync.

1 Like
3

Thank you. This is great. I will experiment with these approaches.

I tried setting a Setting to readOnly in the JSON schema file, and in fact it didn’t have the expected effect.

Thanks again.

4

UX-wise I would not use the .default method (this would be so confusing for users), unless for deprecation (“this setting is now inactive and was only left to prevent breaking validation of your config file”).

1 Like
5

If no changes are expected then why not just make it a constant in the extension codebase? I mean why even make it a Jupyter config. :thinking:

6

The motivation is for the extension to be configurable by the administrator of the application as opposed to the user of the application.

1 Like