We started a normal nim project using vscode nim plugin as our IDE. Once you have subfolders and modules you quickly find a need for the project setup in vscode plugin. We set up a project with its nimscript file and nim.project vscode setting equal to the entry point of the entire project. Everything works as expected, kick start, happy days.
Over the course of 1.5 years our code base has grown significantly and number of dependencies increased, heavy macros have appeared. nim check time for the project went up to 12-14 seconds and as the result vscode nim plugin responsiveness became sluggish. nimsuggest barely able to find anything, most the time it is just hanging and can't do much. Nothing vscode plugin can do about it.
Surprisingly, we have found an interesting solution. Nim actually checks parent directories for configs as well. Here is a prove: nimconf and nimscript.
So if you put your configuration into nim.cfg or config.nims then nim check folder1/folder2/a.file is successful even if config file is located in the root folder. This was a game changer. We have removed nim.project setting and miracle has happened. nim check for a file went down to 0.7-1.2 seconds since it doesn't have to go through the whole project. VSCode plugin is usable again. Nimsuggest works again and responsiveness far better than ever. Much better user experience overall, everyone loves it. Of course many more nimsuggest processes are running now (one per file), but who cares when it works this great.
There is only one problem though. Not every .nim file is a module. There are .nim
files that are included not imported and nim check and nimsuggest for these files
fail completely. Nim compiler codebase also affected as it is using include very often.
We have started to name all included files differently so it can be detected. Using
different extension, say .inim. However we still need a way to map included nim files to the modules they are included from. The idea that we would like vscode plugin to over nim.projectMapping setting that will allow per file mapping and/or wildcard mapping using regex. Examples: (.*).inim => $1.nim or subdir/*.inim => subdir/main.nim. This will sort out the last issue and will allow for larger projects to be developed in Nim.
Here is a story of the nim project.
We started a normal nim project using vscode nim plugin as our IDE. Once you have subfolders and modules you quickly find a need for the project setup in vscode plugin. We set up a project with its nimscript file and
nim.project
vscode setting equal to the entry point of the entire project. Everything works as expected, kick start, happy days.Over the course of 1.5 years our code base has grown significantly and number of dependencies increased, heavy macros have appeared.
nim check
time for the project went up to 12-14 seconds and as the result vscode nim plugin responsiveness became sluggish.nimsuggest
barely able to find anything, most the time it is just hanging and can't do much. Nothing vscode plugin can do about it.Surprisingly, we have found an interesting solution. Nim actually checks parent directories for configs as well. Here is a prove: nimconf and nimscript. So if you put your configuration into
nim.cfg
orconfig.nims
thennim check folder1/folder2/a.file
is successful even if config file is located in the root folder. This was a game changer. We have removednim.project
setting and miracle has happened.nim check
for a file went down to 0.7-1.2 seconds since it doesn't have to go through the whole project. VSCode plugin is usable again. Nimsuggest works again and responsiveness far better than ever. Much better user experience overall, everyone loves it. Of course many more nimsuggest processes are running now (one per file), but who cares when it works this great.There is only one problem though. Not every
.nim
file is a module. There are.nim
files that are included not imported andnim check
andnimsuggest
for these files fail completely. Nim compiler codebase also affected as it is using include very often. We have started to name all included files differently so it can be detected. Using different extension, say.inim
. However we still need a way to map included nim files to the modules they are included from. The idea that we would like vscode plugin to overnim.projectMapping
setting that will allow per file mapping and/or wildcard mapping using regex. Examples:(.*).inim => $1.nim
orsubdir/*.inim
=>subdir/main.nim
. This will sort out the last issue and will allow for larger projects to be developed in Nim.Summary: