feat(wrapperModules.zed): init

[SibaldH]

Summary

Adds a new zed wrapper module.

This provides a Home Manager-like declarative interface for Zed without depending on Home Manager. The wrapper can generate Zed config files and symlink them into the user’s $XDG_CONFIG_HOME/zed directory before launching Zed.

Supported options include:

• userSettings for settings.json
• userKeymaps for keymap.json
• userTasks for tasks.json
• userDebug for debug.json
• extensions, translated into auto_install_extensions
• themes, supporting generated JSON themes and existing theme file paths
• linkConfig, to control whether generated config is symlinked on launch
• forceSymlinks, to opt into replacing existing user config files or symlinks

Design notes

Zed expects its configuration files in the user config directory, so this wrapper does not try to pass a custom config path to Zed. Instead, it generates the config files into the wrapper derivation using constructFiles, then links individual files into $XDG_CONFIG_HOME/zed when the wrapped binary starts.

The default behavior is intentionally conservative: existing real files or unrelated symlinks are not overwritten unless forceSymlinks = true is set.

Testing

• nix fmt
• nix build ./ci#checks.x86_64-linux.wrapperModule-zed -Lv
• nix flake check -Lv ./ci

Reviewer notes

I opened this as a draft because I would like feedback on the config-linking approach.

In particular, I would appreciate feedback on:

1. whether linkConfig = true is a good default;
2. whether the forceSymlinks safety behavior matches the expectations of this repository;
3. whether the option names should stay close to Home Manager’s Zed module names or use more generic wrapper-module naming.

[BirdeeHub]

Im a bit surprised zed modifies its settings file directly rather than using a data dir

This is looking OK in light of that, but you have isPathLike, I am wondering if it might be solved more elegantly with the wlib.types.linkable type?

I also might have another thing or 2 to comment on, will look further.

Sorry, I have been having quite the time the last few weeks I haven't had much time to review PRs

[BirdeeHub]

Im not super sure about this implementation here.

If we are just symlinking it to the correct location at runtime, shouldn't we be setting XDG_CONFIG_HOME ourselves rather than this? If we are symlinking, we do not gain the ability to edit the files, so we aren't getting anything extra out of this rather than setting XDG_CONFIG_HOME

Basically, what I think we should do here is a combo of what we do for helix and for noctalia shell

nix-wrapper-modules/wrapperModules/n/noctalia-shell/module.nix

Lines 347 to 352 in 6e7f66f

	content = ''
	#!${pkgs.bash}/bin/bash
	mkdir -p ${config.outOfStoreConfig} && \
	cp -rn ${config.configPlaceholder}/. ${config.outOfStoreConfig} && \
	find ${config.outOfStoreConfig} ! -perm -u+w -exec chmod u+w {} +
	'';

So, we should use XDG_CONFIG_HOME here and point directly to the store, and then have an option to use an out of store config, which copies it to the location instead like we have for noctalia, that way they can accept runtime edits from the gui if they want out of store, otherwise it is all properly bundled in the store and doesn't need runtime instructions.