If I set a breakpoint in an included file, the breakpoint is not getting hit. Below shows my setup. I simply click the debug button to run test1.jl, the debugger runs and never stops at the break point. Running Julia 1.5.0 and VS Code extension is 1.0.6
Am I doing something wrong? I think this used to work
This was a while ago, but did you figure out a solution? I’m having similar issues.
I don’t know if there was a time when that worked, but I think that breakpoints at the top level of include-d files cannot be hit. The reason is that when you include a file, the interpreter does not walk through its code in the same way as when you run it normally: its code is just turned into a String, which is then passed down to include_string. (You can see how it works in Base._include, in the source file base/loading.jl.)
As far as I understand, the debugger can stop only at the top level of the files you are directly running. And it also stops in the code of included files, if it is used after including it, e.g. in functions:
Say this is “test1.jl”:
include("test2.jl")
foo()
And “test2.jl”:
function foo()
println("Debug me!") # here is the breakpoint
end
Then if you run and debug “test1.jl”, it will stop at the breakpoint.
This is also related to this post and @pfitzseb has created an issue on Github related to top level debugging, currently in backlog (see here)
So do think there is currently a solution (except wrap the code into a function) but thanks to the wonderful VSCode dev, we may have one soon 
Yeah, @heliosdrm is right. It’s unlikely this will be fixed anytime soon.
#2146 is about something different (I clarified the title).
Maybe, instead of trying to debug the code of include-d files, it would be worth to think why this is wanted, and if a different work flow might be a convenient way of achieving the same goal. I have encountered myself in that situation, and this is my analysis of that personal use case:
I had two kinds of files included in my code: (a) files with auxiliary functions, and (b) scripts where I calculated things in a series of steps, and kept all results as globals because later I wanted to look back into intermediate results.
The “function libraries” were no issue: I had no need to debug them at “include time”; maybe I wanted to add breakpoints and debug the functions when I called them later on, but there is no problem with that.
Now, the problem came with the scripts. But why was I executing them with include in the middle of a Julia session? Why the command of “Debug File in New Process” available in the VS Code extension was not good for me? There might be different reasons:
The instructions written in the script were a recipe for an analysis that might be done with different inputs. I created those inputs interactively in the REPL (e.g. reading from files), stored them in variables with fixed names, and then just included the script to run the analysis – which expected those variables with those names. After that, again in the REPL I inspected final and intermediate results, plotted this and that, etc. Running the file that I wanted to debug was just a step in between an interactive session, so this could not be done in a separate new process.
Related to the previous reason: there might be a stage where the interactive toying with inputs and outputs was not needed anymore, I was always doing the same, so everything could be written in a script. But when dealing with multiple repetitions of the analysis (with different inputs), I still wanted to look closely into the process for each input. Run it with data A – ok, everything fine; let’s go with data B – oh, that’s not right, I’ll repeat it in debug mode in order to see what’s happening. This might be done with “Debug File in New Process”, but having to start it in a new process may be slow and annoying.
Different steps of the analysis were written in different scripts, and nested with include in the main script.
For #1 and #2, I realised that what I really wanted to do (run the whole script in a single step) was as easy and fast with the interactive tools of VS Code as by typing include("script.jl"). And those tools also allowed me to stop in a given line without breakpoints, e.g. starting a new code cell right before the target code block, and running the file by code cells (Alt + Shift) – well, except if I wanted to stop right in the middle of a loop or another code block.
What I really missed is some kind of shortcut that does the same as “Send Current Line or Selection to REPL” (Ctrl + Enter), but prepended by @run or @enter, to start debugging the target line without having to copy-paste it manually in the REPL.
For #3, well, I had no solution. So I have accustomed myself to avoid that pattern of nesting includes in scripts. Looking into it with another perspective, I think that this has also helped me to write cleaner code, e.g. replacing such things by functions when suitable.
Discussion on #1674 seems to indicate otherwise…