Debug application built on local Meteor packages

[cybairfly]

Reporting this as an issue because I consider it a serious problem and refuse to accept there is no viable official solution after doing some research.

How can one debug local Meteor packages? I mean by setting up breakpoints within the packages in the IDE just like in any other codebase. Please don't dismiss the question with an offer to scatter temporary "debugger" statements all over the codebase or set breakpoints somewhere in compiled code, completely out of the context of the project's workspace as these are not really a viable replacement for registering breakpoints in the IDE for many obvious reasons. I am working on a project built almost entirely on local Meteor packages to enable custom modular deployment of the application for different clients and breakpoints don't get picked up within packages for some reason and application won't stop on them which is a crucial pain point of the development to the point I don't understand how anyone else might be just silently ignoring this problem and getting by. I've seen some poor workarounds like the ones mentioned above but no real solution anywhere. Please do advise on this.

• [x] The version of Meteor showing the problem. Any version including the new one
• [x] The operating system you're running Meteor on. Win 10 (VSCode)
• [x] The expected behavior. Breakpoints work within local packages
• [x] The actual behavior. Breakpoints don't work within local packages
• [x] A simple reproduction! (Must include the Github repository and steps to reproduce the issue on it.) Click any line in the gutter to set up a breakpoint in package code in VSCode & run the project.

Thanks in advance!

[cybairfly]

@StorytellerCZ Mr. Story teller, do you happen to have a story to tell on how you tackle this issue please? Is there any solution?

[harryadel]

If I understand correctly you want to debug your application which uses local packages yet you don't want to use 'debugger' statements, correct? Would enabling Vscode debug server help out in your situation? https://forums.meteor.com/t/meteor-1-6-server-debugging-with-vs-code/39821

[cybairfly]

@harryadel I appreciate your response! Indeed - hard-coding temporary debugger statements and then cleaning up is honestly pure madness compared to simply setting a visual breakpoint in IDE, not to mention it requires a recompile on every single such change (getting shivers). Thanks for sharing the link but I'm not sure what you mean. I do use the built-in VSCode debugger and have tried many configurations. Regular Meteor setup (server / client) works just fine - the problem is solely with local packages where breakpoints set in the IDE are completely ignored. Am I missing something? It seems to be a common issue and I find it hard to believe it's accepted by the Meteor community.

[cybairfly]

Do you have any further thoughts on this please? @harryadel

[denihs]

Hi @cybairfly,

I did some tests on Webstorm, which is the IDE that I use daily, and as you can see in this video, the debugger works perfectly there... This makes me think that this isn't a problem directly related to Meteor but with VSCode.

As far as I know, we don't do anything special to make this work on Webstorm, but yet, it still works.

Maybe we could try to create a plugin to fix this behavior, but it's out of my scope of knowledge, so I don't know if it would work. As this isn't exactly a bug, and it's more of a feature request, we would have to add this to our Roadmap. As you may know, our Roadmap is defined through our discussions https://github.com/meteor/meteor/discussions. So, it would be best if you moved this to a discussion. If it gets enough upvotes and traction, it will become a priority.

For now, you could try to get the VSCode team's attention on this, at least to have their perspective on how this could be solved.

You can also try this new plugin that some community members created https://forums.meteor.com/t/meteor-toolbox-vs-code-extension/58044. It doesn't seem to be directly related to this issue, but it could help.

Also, my advice for you would be to try Webstorm. It works there, so you'll save some time.

[harryadel]

Alright so after looking around I stumbled upon this issue which describes your problem exactly; debugger statements work but not break points.

So, A) Try updating your application to 1.6.1 at least B) Add "protocol": "inspector" to your launch.json configs

I'm having a bit of trouble testing things locally but try these variations of launch.json: https://forums.meteor.com/t/vs-code-server-debugging-with-meteor-1-10/53437/8?u=harry97

  {
      "type": "node",
      "request": "attach",
      "name": "server",
      "restart": true,
      "port": 9229
    },

According to this comment, try the previous config but listen to port 5959

      {
        "type": "node",
        "request": "attach",
        "name": "Attach to meteor 5959",
        "port": 5959,
        "restart": true,
        "sourceMaps": true
    }   

These are my thoughts for now, please let me know how it goes, thanks!

EDIT: According to your comment @brucejo75 you were able to figure it out, mind sharing your launch.json configs please? Also, @zodern I know you're a big fan of vscode so what's your take on this?

[harryadel]

Funnily enough, I was using 2.6 application to test this problem once I updated it to 2.6.1 and used the official vscode recipe, it worked! FYI, I'm testing a breakpoint in a locally cloned package as you can see from the path packages/monti-apm-agent/lib.

[brucejo75]

Hey @harryadel, sorry I switched back to debugging using chrome://inspect, cannot remember why. I have no trouble setting breakpoints in local packages with chrome://inspect.

Maybe I will take another shot at debugging in VSCode when I have a few minutes (hours) to sort out config.

PS: thanks for the pointer to the vscode recipe.

[cybairfly]

Hi @denihs I appreciate your time and detailed response. Thank you for taking your time to make the recording.

Let me ask a crucial question: Do you know of anyone who has been able to debug code in packages using any other IDE than Webstorm or do people just give up on it?

While you may not be doing anything special to make debugging packages work in Webstorm on your end, it does look like that responsibility was simply shifted to them (Jetbrains) where they had to add special features to provide that functionality:

https://youtrack.jetbrains.com/issue/WEB-16337 https://forums.meteor.com/t/package-debugging-in-webstorm-is-finally-supported/13938/1

You can search the forums to discover this seems to be a rather common problem within the Meteor community, without any clear solution proposed in any of the discussions. Forcing developers into a specific commercial IDE to support basic features like debugging is out of the question as a viable solution, therefore I will not even consider it being one - I will not migrate to Webstorm over this for sure, therefore there is no point in testing it there for me.

I don't see the point in transferring this issue over to VSCode team either - since it's a purely Meteor-packages-specific issue, which doesn't occur anywhere else, therefore it will be most likely circling back here pretty quickly. I mean I can try, just don't see the value in it as I've already used the official debugging setup recommended by them which works fine but simply not in Meteor packages: https://github.com/Microsoft/vscode-recipes/tree/master/meteor

Lastly, thank you for sharing the extension - I've tried it and it didn't help - it just creates certain launch configuration and also rewires the packages for IntelliSense support which I've done before to work around the fact that Meteor packages also break the usual implicit linkage between module imports and their origins. The launch configuration did not fix the debug problem.

[radekmie]

Let me ask a crucial question: Do you know of anyone who has been able to debug code in packages using any other IDE than Webstorm or do people just give up on it?

I never used an IDE per-se and when it comes to Meteor, I ran it with --inspect and do everything in the Node inspector.

[harryadel]

Let me ask a crucial question: Do you know of anyone who has been able to debug code in packages using any other IDE than Webstorm or do people just give up on it?

I never used an IDE per-se and when it comes to Meteor, I ran it with --inspect and do everything in the Node inspector.

Honestly, I thought about recommending this way too but @cybairfly seems to be bent up on getting vscode to work which is a legitimate concern for sure.

[cybairfly]

@harryadel I'm grateful for your feedback and follow-ups. Interesting findings you have there!

I've tried many different config permutations found around the Meteor forums but none of them have helped with the packages. The protocol property generated by the extension linked by @denihs yields an error in the launch configuration so it is most likely no longer supported: Property protocol is not allowed. Up until recently I had to deal with Meteor 1.8.3 but the project has been finally updated and now runs on Meteor 2.6, therefore Meteor version should be no longer a concern. AFAIK - the debugging port should have no effect and indeed it does not seem to change anything as it's just a socket to communicate on. It's great news if you can debug local packages in VSCode on your end and makes me wonder what could be the difference - in any case it looks like there is actually hope. Next step will be for me to try with the repository you mentioned to reproduce the environment and see if the problem persists. I'm wondering whether WSL can have anything to do with this. Nevertheless, I believe there should be an official recommendation from Meteor, well documented debugging setup for packages in VSCode. I'll be glad to help with documenting that if we manage to figure this out @denihs Discussions and examples in the forums are often left unresolved and abandoned so it's difficult to find there anything of value. Apparently, there is no clear consensus on how to approach this in VSCode reliably, leading to even seasoned members of the community to make various compromises or perhaps even give up on debugging packages altogether which is unimaginable.

[harryadel]

Up until recently I had to deal with Meteor 1.8.3 but the project has been finally updated and now runs on Meteor 2.6

Make sure it's 2.6.1 at least.

[cybairfly]

@harryadel I see. Mind sharing why? Is there a known issue with debug features in lower versions? Asking since it's already quite recent version at least compared to what the project had to run on until recently.

@brucejo75 @radekmie thanks for chiming in also. Please let us know if you recall what lead you to the decision to abandon the ability to set breakpoints right from the IDE and accept having to use an extra debug tool for the job (I assume DevTools)

Regarding the VSCode recipe it is not even necessary from my experience - for anything other than packages, debugging does work just fine. Meaning the client/server project structure. No problem there - and no special config needed.

[harryadel]

@cybairfly

According to your https://github.com/meteor/meteor/issues/8590#issuecomment-336541047 @brucejo75 you were able to figure it out, mind sharing your launch.json configs please? Also, @zodern I know you're a big fan of vscode so what's your take on this?

See the referenced issue please. In a nutshell, Meteor wasn't exporting source-maps pre 2.6.1 which made vscode unable to detect these breakpoints but only able to stop on debugger statements.

[cybairfly]

@harryadel I did but did not consider it quite current and relevant since it's dated 2017 at Meteor 1.6 even before "using the new inspector protocol" and if it's still valid and relevant then that would just prove the long standing history of debugging problems in Meteor. Did you have something else in mind I might have missed?

[harryadel]

I'm a bit confused by your comments. Did you update to 2.6.1 or later? Please don't make any bold assumptions about Meteor, you've not been around enough. Finally, you're keeping us in the dark, man. Can you please create a mini-repo (excluding any proprietary code of yours, just enough to replicate the setup) including launch.json configs? Thanks!

[cybairfly]

@harryadel sure, I understand it's difficult to reason without the context. I can't share the code since it's a commercial application and updating the version will require team involvement but I can experiment with some minimum reproductions and share what I find, including a local update of the Meteor version to >2.6.1 I do thank you! Will update.

[denihs]

Hey @cybairfly, I can see things more clearly now. I also agree it should work properly with VSCode.

I don't call the shots on our roadmap, so I can't promise you this will become a priority right away, but I'll bring this internally, and hopefully, we'll have a proper position about this matter soon.

For now, you can provide a reproduction, as @harryadel suggested, so that we can do further investigation.

Also @harryadel, thank you very much for your work here. Really great insights.

[cybairfly]

@denihs thank you and looking forward to figuring this out together, hopefully sooner rather than later. Meanwhile,

@harryadel can you please elaborate on how to reproduce your setup? I've cloned the repo you linked to but cannot see any local packages in there. The issue is debugging packages as defined in https://docs.meteor.com/api/packagejs.html

Do I miss something?

[harryadel]

The repo I linked was nothing but some random Meteor package which I used in conjunction with a 2.6.1 Meteor app to verify whether breakpoints trigger or not. I explicitly made that clear.

I'm testing a breakpoint in a locally cloned package

Anyway, here's a reproduction app I span up for you. It basically contains a faulty check statement and we place a breakpoint in the locally cloned check package.

[radekmie]

@cybairfly

@radekmie thanks for chiming in also. Please let us know if you recall what lead you to the decision to abandon the ability to set breakpoints right from the IDE and accept having to use an extra debug tool for the job (I assume DevTools)

I haven't abandoned it as I never used it. I work with a few completely different technologies on a daily basis (C++, Rust, Nim, Lua, JavaScript) and I use the same editor for all of them. And as I work like this for years now, I'm just used to it.

Also, I like to have all of the tools in one place - in Chromium's DevTools you can do much more than only setting breakpoints (e.g., log points, memory dump, or simply executing console while paused in debugger).

[cybairfly]

@harryadel thanks for taking the time to prepare the repo. I didn't grasp your original remarks about version upgrade before reading again a couple times due to the missing punctuation. Glad you got it to work and I can confirm that the repro running on Meteor 2.7.2 does stop on a randomly placed breakpoint in the local check package as depicted here:

I've meanwhile done more tests with other developers to rule out any effect of OS platform and local setup, all with identical results using the official VSCode recipe on Macs. Webstorm does work fine as discussed before and confirmed again through testing. I have yet to succeed in updating Meteor due to extreme CPU usage and installation time - will update on that later.

It was only now that I read this remark after missing it previously, which would make sense (omitting the assumption that this has been addressed after about 5 years since the first reports of the problem on the forum):

In a nutshell, Meteor wasn't exporting source-maps pre 2.6.1 which made vscode unable to detect these breakpoints but only able to stop on debugger statements.

I will try to confirm this soon and would have long by now if Meteor could actually install on a Windows machine, even in WSL (yes, AV and firewall are disabled, not to mention the dubious nature of such requirement to merely install a web framework).

Finally, as always, thank you. I do appreciate your support.

[cybairfly]

@radekmie I see. Correct me if I'm off but I believe the built-in debugger to be fairly competent. I'm pretty sure you can do all of the mentioned in the VSCode debugger as well - including logger points, profiling and real-time REPL throughout debug session. It feels completely natural to use a single tool for all of that rather than having to connect a separate tool via web sockets only to be able to debug what you are already working on in the IDE with all the modules open and work in progress.

[cybairfly]

Finally, managed to upgrade local Meteor version of the project in question to latest to test your suggestion @harryadel and the problem remains so it seems to come down to the combination of a specific IDE and project setup since Webstorm already does have some logic to handle this case correctly. What would you recommend to do? Do you suspect what might be causing the problems on our end in terms of the project setup and what Webstorm could be doing to avoid this issue?

[cybairfly]

Note that the problem has been reported multiple times by different people so it must be something specific in the setup and not only about the project. I wonder what the reasons might be.

[cybairfly]

I suspect this might have something to do with the custom package manager used by the application but have not investigated in depth. Do you have any thoughts on that? @vojtechobrusnik

[vojtechobrusnik]

With the knowledge of the mentioned custom package manager, its influence on the topic discussed is impossible.