Breakpoints Don't Hit -- WebStorm

[marc-wilson]

Breakpoints Don't Hit -- WebStorm

[MaxKless]

I was initially quite opposed to the idea of changing the command that is invoked, tbh.
But I see your point and I'm going to play around with passing a --sourceMap flag if the underlying executor supports it

[MaxKless]

hey!
So I just did some more research. There actually aren't very many executors left that expose a --sourcemap flag or something similar. You have to configure it yourself in the underlying tooling config, for example webpack or vite.

This means that I've chosen not to build logic that automatically generates source maps for those few executors that still support it. It's not worth the maintenance burden on the team & I want to reduce the amount of magic that happens.

I have, however, added a periodic notification when running targets through debugging. This means that users will find the root cause of their breakpoints not hitting faster (see the PR above).

I know this probably won't make you very happy, but since Nx is technology-agnostic, we can't assume too much about the things you're using and how to ensure debugging works.

Thanks :)

[marc-wilson]

If you add debugger; to the code, the breakpoints hit, but they are hit in a js file in the dist. Then, there's also a suspicious line in the serve now:

nx run myproj:build [existing outputs match the cache, left as is]

webpack-cli build --node-env=production

Looks like something is forcing a production build during serve. I'm assuming this is what's leading the prod build and therefore berakpoints not working.

[marc-wilson]

Found the reason in #2042.

Sourcemaps should be enabled by default for any development configuration. With today's monitoring solutions available, it's also very beneficial to have hidden source maps generated for the underlying monitoring software. Making a change that makes debugging not work out of the box is completely counter-intuitive for why someone would want to use something like nx-console.

[MaxKless]

Can you elaborate on how nx console is involved here? How could the IDE plugin generate source maps?

[marc-wilson]

Judging from the comment in the other issue, that seems to be the culprit. Whether that is an nx-console or an nx thing is beyond me. But, I do know that this was working perfectly fine so either nx-console did something or nx did something.

I haven't ever developed a plugin for a JetBrains IDE so I am not sure what the process is. But, I would imagine that the plugin is generating a profile/configuration to run the underlying project based on the project.json.

That configuration has arguments and properties. For example, angular cli has --source-map. So, when you're generating the configuration, maybe throw that flag in?

The reason why I think this is more of an nx-console problem is that you get the below UI in WebStorm when you install nx-console:

This implies that I am able to set a breakpoint and run the project if I chose to run the Debug profile. Even the console output says a debugger is attached. It's extremely misleading.

[MaxKless]

Ultimately, we can't guarantee that whatever is run will have source maps. You can also run any arbitrary command through this debug button and those might not support source maps or be configured correctly. So while this should handle more use cases natively, it's no guarantee.

[marc-wilson]

I think this became an issue somewhere in NX 17 per this comment: #1967 (comment)

My guess is that the only reason why this used to work for me was because nx-console is expecting source maps to be there and nx decided to not generate them. So, adding the flag should be the fix.