Summary
Currently, there exists a problem in dev workflow that if a module actually removed from the codebase it still resides in the compile output and is available as if it existed originally.
This happens in the following cases:
1) The first scenario is the module name update in a source file.
If in existing source file user renames a module say it removes module MyModule where -> module MyModuleRenamed where then we build the project (or Language server sends a fast recompile command of changed file) then we happen to have in the output both MyModule and MyModuleRenamed dirs. And in cache-db.json two entries mapping to the same original source file path.
"MyModule": {
"src/MyModule.purs": [...]
},
"MyModuleRenamed": {
"src/MyModule.purs": [...]
},
We have MyModule available as compiled, though the user's expectation is that it should be not.
2) The second scenario is rename/move of a source file (and updating the module name after this).
If the user renames the source file from MyModule.purs -> MyModuleRenamed.purs (withoug changing the content). LS in this case sends the command to rebuild new saved file (MyModuleRenamed.purs). After this In cache-db.json file path is not updated, it is still:
"MyModule": {
"src/MyModule.purs": [...]
},
though what would be expected:
"MyModule": {
"src/MyModuleRenamed.purs": [...]
},
and if after this user updates the module name module MyModule where -> module MyModuleRenamed where we get in cache-db:
"MyModule": {
"src/MyModule.purs": [...]
},
"MyModuleRenamed": {
"src/MyModuleRenamed.purs": [...]
},
Again we have MyModule available as compiled, though the user's expectation definitely is that it should be not.
3) The third scenario is a source file deletion. When a user just wants to remove the module from the codebase.
Currently, LS doesn't send any commands to purs-ide, so the things stay as they are, and the deleted module is still available as compiled. Though in the normal workflow it is expected to be removed from the compilation results and no to be available.
Motivation
To support common workflow use expectations and improve DX.
Proposal
-
When purs-ide receives a rebuild command for the source file it should keep one to one correct mapping of the module name to the source path. Though this also refers to a normal purs compile cli command.
-
Remove non-existing modules (based on the absence of the corresponding source file) from the compilation result.
-
Deletion of the source file workflow could be either supported by a separate purs-ide command, or just rebuild command could be used: if purs-ide gets the command to rebuild MyModule.purs and this file doesn't exist, it should not just give an error, but if there is a compilation result that maps to this file it should be removed.
Summary
Currently, there exists a problem in dev workflow that if a module actually removed from the codebase it still resides in the compile output and is available as if it existed originally.
This happens in the following cases:
1) The first scenario is the module name update in a source file.
If in existing source file user renames a module say it removes
module MyModule where->module MyModuleRenamed wherethen we build the project (or Language server sends a fast recompile command of changed file) then we happen to have in the output bothMyModuleandMyModuleRenameddirs. And in cache-db.json two entries mapping to the same original source file path.We have MyModule available as compiled, though the user's expectation is that it should be not.
2) The second scenario is rename/move of a source file (and updating the module name after this).
If the user renames the source file from
MyModule.purs->MyModuleRenamed.purs(withoug changing the content). LS in this case sends the command to rebuild new saved file (MyModuleRenamed.purs). After this Incache-db.jsonfile path is not updated, it is still:though what would be expected:
and if after this user updates the module name
module MyModule where->module MyModuleRenamed wherewe get in cache-db:Again we have
MyModuleavailable as compiled, though the user's expectation definitely is that it should be not.3) The third scenario is a source file deletion. When a user just wants to remove the module from the codebase.
Currently, LS doesn't send any commands to purs-ide, so the things stay as they are, and the deleted module is still available as compiled. Though in the normal workflow it is expected to be removed from the compilation results and no to be available.
Motivation
To support common workflow use expectations and improve DX.
Proposal
When purs-ide receives a rebuild command for the source file it should keep one to one correct mapping of the module name to the source path. Though this also refers to a normal
purs compilecli command.Remove non-existing modules (based on the absence of the corresponding source file) from the compilation result.
Deletion of the source file workflow could be either supported by a separate purs-ide command, or just
rebuildcommand could be used: ifpurs-idegets the command to rebuildMyModule.pursand this file doesn't exist, it should not just give an error, but if there is a compilation result that maps to this file it should be removed.