Add commands to link or unlink V projects

[gchumillas]

Describe the feature

Add commands to link or unlink V projects in the same way as npm does: https://docs.npmjs.com/cli/v9/commands/npm-link

Use Case

Sometimes, when we're working on a project, we create convenient libraries to better organize the code. To ensure these libraries recognize each other, we need to create their corresponding symlinks:

# link library
ln -s $PWD/mylib ~/.vmodules

# unlink the library
rm ~/.vmodules/mylib

But those commands are complex, error-prone and difficult to remember, and the situation described above is very common.

Proposed Solution

Create two commands to link | unlink projects locally:

# link the current project
v link

# unlink the current project
v unlink

Other Information

No response

Acknowledgements

• [ ] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

Version used

V 0.4.10 d9b808c

Environment details (OS name and version, etc.)

V full version	V 0.4.10 dead5e69b44b4f8c4999ac82b730c21250cb0583.d9b808c
OS	macos, macOS, 15.4.1, 24E263
Processor	8 cpus, 64bit, little endian, Apple M1 Pro
Memory	0.22GB/16GB
V executable	/Users/gonzalo/Projects/Personal/v/nv/v
V last modified time	2025-04-26 21:07:34
V home dir	OK, value: /Users/gonzalo/Projects/Personal/v/nv
VMODULES	OK, value: /Users/gonzalo/.vmodules
VTMP	OK, value: /tmp/v_501
Current working dir	OK, value: /Users/gonzalo
Git version	git version 2.39.1
V git status	weekly.2025.17-5-gad3dc7b5 (32 commit(s) behind V master)
.git/config present	true
cc version	Apple clang version 17.0.0 (clang-1700.0.13.3)
gcc version	Apple clang version 17.0.0 (clang-1700.0.13.3)
clang version	Apple clang version 17.0.0 (clang-1700.0.13.3)
tcc version	tcc version 0.9.28rc 2024-02-05 HEAD@105d70f7 (AArch64 Darwin)
tcc git status	thirdparty-macos-arm64 e447816c
emcc version	N/A
glibc version	N/A

[!NOTE] You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote. Other reactions and those to comments will not be taken into account.

[huly-for-github[bot]]

Connected to Huly®: V_0.6-22760

[jorgeluismireles]

Alternatively, maybe mod.v file dependencies could include (with some syntax) an alternative path other than .vmodules where to look for the modules.

Module {
	name: 'you_proyect',
	description: "...",
	dependencies: [
		"my_module @ [path ../../my_module]"
	],
}

So by modifying mod.v we can test a local module and then change it to get again the .vmodules version.

In golang a replace directive in file go.mod permits to access a package not from the open-source git repo (with usual require directive alone) but from a relative folder in your system so you compile your private sources and the library remains closed-source. I asked from some similar here https://github.com/vlang/v/discussions/22127 and I think is related with your request.

[gchumillas]

The problem with that approach is that we could accidentally add those local dependencies to the Git repository.

[gechandesu]

I was thinking about this in the context of the new VPM implementation. Local dependencies can be resolved by creating symbolic links in the modules directory. VPM can read the specification from v.mod and create the symlink. /modules must be added to .gitignore.

lib/
  |__ v.mod
  |__ ...
app/
  |__ modules/
      |__ lib --> ../../lib
  |__ main.v
  |__ ...
  |__ v.mod

This solution would not require changes to the compiler, since the local modules directory is already in the module search path. Also the global VMODULES dir is not polluted.

[JalonSolov]

There has been talk off & on of removing modules as any type of special directory. It would be just another subdir.