You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the language server initializes a workspace by recursively scanning the root directory and parsing all scripts and config files. Even with parallel compilation, this can lead to a startup time on the order of ~10 seconds for a large project like nf-core/rnaseq.
It would be nice to have the option for a more lightweight startup. For example, when I open a file, just parse that file and its includes. Maybe you still do the full scan afterwards, because at that point it shouldn't block the current file from having code intelligence.
We could tie this to the "Extended completions" setting. This is the main reason why I need to scan the entire workspace, so that I can provide completions for external definitions. The full scan also allows you to see all errors across the workspace, but if I open the main script in this lightweight mode, I will get the same errors I would get when running it.
Another question is how to handle config files vs scripts. If I open a script in lightweight mode, should the language server automatically load nextflow.config in the same directory? That would be consistent with run, but also, the user can specify arbitrary configs at run-time, so we can't really guarantee "consistency" here anyway. As a first iteration, maybe better to not try to be smart here.
The text was updated successfully, but these errors were encountered:
Currently the language server initializes a workspace by recursively scanning the root directory and parsing all scripts and config files. Even with parallel compilation, this can lead to a startup time on the order of ~10 seconds for a large project like nf-core/rnaseq.
It would be nice to have the option for a more lightweight startup. For example, when I open a file, just parse that file and its includes. Maybe you still do the full scan afterwards, because at that point it shouldn't block the current file from having code intelligence.
We could tie this to the "Extended completions" setting. This is the main reason why I need to scan the entire workspace, so that I can provide completions for external definitions. The full scan also allows you to see all errors across the workspace, but if I open the main script in this lightweight mode, I will get the same errors I would get when running it.
Another question is how to handle config files vs scripts. If I open a script in lightweight mode, should the language server automatically load
nextflow.config
in the same directory? That would be consistent withrun
, but also, the user can specify arbitrary configs at run-time, so we can't really guarantee "consistency" here anyway. As a first iteration, maybe better to not try to be smart here.The text was updated successfully, but these errors were encountered: