Debug application built on local Meteor packages
- Dominant language
- JavaScript
- Stars
- 44.8k
- Forks
- 5.2k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 25
Description
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!
Contributor guide
Research direction
The issue names no source files, tests, entry points, or reproduction repository. Begin by reproducing the breakpoint failure in a local Meteor package on Windows 10 with VSCode, then trace how the project handles package debugging; done means IDE breakpoints stop within local package source.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, vscode
- Domain
- developer-experience, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100