Vscode-php-debug: Stop using enableBreakpointsFor in package.json under debuggers contribution

[isidorn]

Hi VS Code dev here 👋

Please stop using the enableBreakpointsFor field in your package.json.
It is deprecated and we will stop supporting it in our next stable release (in a month).
Here's where you use it https://github.com/felixfbecker/vscode-php-debug/blob/master/package.json#L119

Here's an alternative how you should use it
https://github.com/microsoft/vscode-mock-debug/blob/master/package.json#L112

So the breakpoints attribute is no longer under debuggers that is the difference.

Here's how react native tackled this deprecation https://github.com/microsoft/vscode-react-native/issues/1450

All the best
isidor

[aredridel]

This just bit me in the insiders release, thank you for reporting it @isidorn!

[JulianCBC]

Just so the severity of this is clear: this breaks the extension rendering it almost _completely_ unusable.

@felixfbecker I note that you haven't done any development on this extension in over a year, if you've abandoned it, please make that clear so people's expectations are set appropriately.

[isidorn]

Please note that a fix for this is a 10 minute effort I think.
If nobody from the mainterns whats to do it and if nobody from the community is interested I can create it.

[JulianCBC]

@isidorn the issue isn't necessarily the fix, it's a completely trivial change to the point that I'm surprised VSC doesn't have some form of permanent backwards compatibility, the issue is releasing this in Felix's name, which you can't do.

Felix hasn't touched this repo in over a year, and there are two forks with both more active development and packages published in the VSC extension directory:

• https://github.com/tiansin/vscode-php-debug.git
• https://github.com/robberphex/vscode-php-debug.git

@tiansin's fork has fixed this particular issue and Works For Me as a replacement to this extension.

So if Felix has indeed abandoned this extension, the best path forwards is to make that clear (whatever that means) so people know to migrate to one of these forks.

[MattGrdinic]

Yup. And by not fixing this before a full release, you've just broken the 3.9 million installs this extension has.

[dsclee1]

I've created a pull request to fix the issue. #428

[lwohlhart]

rather unfortunate deprecation policy but well, okay.
Does anybody have a guess if @felixfbecker will continue.
Really love his work would hate to have to swap to another implementation.

[xpertbot]

For other developers that need this extension to work for time sensitive projects and need a quick fix, I am unsure when @felixfbecker will apply this fix. I forked the repo and added the recommended fix into it, also published the extension for others, it lives here. Note: I will not maintain it, I just need the extension to work without affecting my workflow completely.

[aredridel]

Do note there are two other forks.

[xpertbot]

@aredridel I saw them and was planning on contributing to them however, 1 is in Chinese, which I do not speak.. and the other last commit was on 2019, so it's multiple versions behind. Just wanted to share a quick fix that will work for the time being, until @felixfbecker fixes it.

[gentig]

You can fix this by doing the following:

1. go to vscode extension directory: e.g. .vscode\extensions\felixfbecker.php-debug-1.13.0
2. Open package.json then remove the following from the file

"enableBreakpointsFor": {
          "languageIds": [
            "php"
          ]
        },

and add the following right above "debuggers"

"breakpoints": [
            {
                "language": "php"
            }
        ]

1. Reload vscode

[RAFA3L]

Thanks @gentig

[jplackey]

Does anyone know if this bug only applies when debugging locally? I'm using Remote-SSH, and in /.vscode-server/extensions/felixfbecker.php-debug-1.13.0, I currently have the old/original enableBreakpointsFor settings, and I'm able to set and hit breakpoints without issue. (also need to try w/ Remote-WSL)...

[lwohlhart]

@jplackey the problem is the newest VScode release 1.52.0 where they deprecated the "enableBreakpointsFor" declaration.
I guess if you have an older VScode version everything is fine and once you update to 1.52.0 it'll also not work anymore.

Seems like it doesn't have anything to do at all with the actual debugging capability ( breakpoints that were set in certains scripts before i updated also still trigger ); just the GUI for setting breakpoints died because VScode now believes none of your extension provides a breakpoint handler for PHP

[jplackey]

@lwohlhart Thanks for the response. I'm on Windows 10, and I did get updated to 1.52.0 today. No issue on my end setting breakpoints (both with F9 and via the gutter). Was able to set a new breakpoint within a PHP file locally, in a Remote-SSH file, and in a Remote-WSL file. :shrug: (edit: I have "allow breakpoints everywhere" enabled, which is why I didn't see the issue).

[weinand]

As a workaround, you can use this setting to enable breakpoints everywhere:

BTW, the suggestion made in https://github.com/felixfbecker/vscode-php-debug/issues/424#issuecomment-743334478
does not have to live in the php-debug debug extension (or a fork of it).
Instead a trivial extension could be created that just contributes this:

"breakpoints": [
  {
    "language": "php"
  }
]

[lwohlhart]

Good news ! Thanks guys

[taeho-yoo]

Thank you @weinand You saved my day with your solution.

[MarkusRodler]

Do note there are two other forks.

http://imgs.xkcd.com/comics/standards.png

😄

[anrikun]

Thanks @gentig
But don't forget to add a comma after ] or it won't work.

 "breakpoints": [
            {
                "language": "php"
            }
        ],

[gabpe]

Thanks @gentig
Only for whom how me :)
"breakpoints": [{
"language": "php"
}],
"debuggers": [{
"type": "php",
"label": "PHP",
...

[isidorn]

We will push a workaround for this on the VS code side in the next stable release - probably in a couple of days.

[stevewh]

So what do I do today. I just switched and I'm at completely stopped on my project. Revert to 1.51.0? Balmer would have had a hay day with this. :-| Guys, this is a SEV1, please treat it as such and do the right thing.

[lwohlhart]

So what do I do today. I just switched and I'm at completely stopped on my project. Revert to 1.51.0? Balmer would have had a hay day with this. :-| Guys, this is a SEV1, please treat it as such and do the right thing.

I'm fully on board with you w.r.t the SEV1.
But today, my friend you do the right thing, and tick the box in the setting as stated by @weinand
https://github.com/felixfbecker/vscode-php-debug/issues/424#issuecomment-743458417

[stevewh]

Yep, just did. Took too long to find it. For other. VsCode setting/ Features/Debug first setting. Only cost an hour. Cheers.

As another thought, is there a way to get this message front and center for devs that you know will hit this or any other future issue like it? A sticky comment at the beginning of this issue? A bold note or vid in the Release Notes?

[alexkuc]

Yep, just did. Took too long to find it. For other. VsCode setting/ Features/Debug first setting. Only cost an hour. Cheers.

As another thought, is there a way to get this message front and center for devs that you know will hit this or any other future issue like it? A sticky comment at the beginning of this issue? A bold note or vid in the Release Notes?

As the extension stands:

• latest commit on 6 Mar 2019
• there are 32 opened PRs
• there is almost 50% of open issues

So speaking objectively, looks like this plugin is abandoned for active development. And this is open source, not a paid product so support comes in a form of direct fixes from authors, PRs and self-help.

TL;DR: it sucks that this extension is abandoned given how popular it is but at the same time I think it is unreasonable to demand immediate support from authors when they give their products for free

On a side, I think either active fork should happen or additional members should be added so that they can actively make commits and merge PRs.

[stevewh]

I'm up for helping, as the debugger with docker let's me work in a
simulated environment (with 200k+ lines of code, I depend on it) for the
diversity of install environments I work with.

On a side note, it's reasonable to consider 3M PHP Debug users as quite a
crowd and a heavy impact on a SEV1 release. Assuming the install knows one
has the extension how hard is it to have a popup asking to "tick the allow
breakpoints anywhere"? Would have made this seamless for me and add to the
VSCode brand.

If I weren't happy with VSCode this would have been a deal breaker. Thanks
for the response and help.

Let me know if I can help.

On Wed, Dec 16, 2020 at 4:55 PM Alexander Kucheryuk <
[email protected]> wrote:

Yep, just did. Took too long to find it. For other. VsCode setting/
Features/Debug first setting. Only cost an hour. Cheers.

As another thought, is there a way to get this message front and center
for devs that you know will hit this or any other future issue like it? A
sticky comment at the beginning of this issue? A bold note or vid in the
Release Notes?

As the extension stands:

• latest commit on 6 Mar 2019
• there are 32 opened PRs
• there is almost 50% of open issues

So speaking objectively, looks like this plugin is abandoned for active
development. And this is open source, not a paid product so support comes
in a form of direct fixes from authors, PRs and self-help.

TL;DR: it sucks that this extension is abandoned given how popular it is
but at the same time I think it is unreasonable to demand immediate support
from authors when they give their products for free

On a side, I think either active fork should happen or additional members
should be added so that they can actively make commits and merge PRs.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/felixfbecker/vscode-php-debug/issues/424#issuecomment-746523955,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARYOIO74QFBPHN627NXJNLSVDJ7VANCNFSM4TSDUFPQ
.

[alexkuc]

On a side note, it's reasonable to consider 3M PHP Debug users as quite a
crowd and a heavy impact on a SEV1 release.

Not really... Who is going to compensate developers for their time? Developers pay their bills in currency, not GitHub stars and forks. Everyone's circumstances change. When you have free time, you can contribute to open-source projects. When you don't have that time, you don't contribute.

Just because something is really popular or in constant demand does not mean its maintenance and support is free.

Some companies which actively rely on open-source either sponsor authors or contribute their employee's (paid) time towards maintaining the repositories.

Let me know if I can help

As an example, someone could fork this repository, set up CI, publish extension on VSCode marketplace and add active contributors, I suppose the whole issue would be resolved.

[weinand]

Two clones of this extension have already fixed the issue.
Please see this comment: https://github.com/felixfbecker/vscode-php-debug/issues/424#issuecomment-727932756

[JulianCBC]

We seem to be re-treading a lot of the same ground here.

For those who got here late, _please read the comments before commenting_.

To summarise:

• @felixfbecker has apparently abandoned this extension, so expecting an update from him is probably unrealistic
• The simplest solution is to enable breakpoints everywhere: https://github.com/felixfbecker/vscode-php-debug/issues/424#issuecomment-743458417
• A "better" solution is to switch to one of the two forks in the VSC repository. I switched to the Tiansin one as the other one (the "Chinese" one) didn't work for me: https://github.com/tiansin/vscode-php-debug.git

Actions from here are either:

1. @felixfbecker flags this as abandoned and passes the torch to one of the other extensions
2. @felixfbecker passes ownership of this repository to someone else so they can start sorting through the issues and PRs
3. VSC adds a workaround (either compatibility with ancient extensions or detection of ancient extensions and an offer to enable breakpoints everywhere)

[stevewh]

Both great points and I saw the response before. My point is a little
different.

The problem and work around were known on Dec. 11. Since I was in the
middle of a feature, I didn't update immediately. I updated on Dec. 16th
and immediately hit the problem. I would have liked to know (via a "push me
the info" solution) when I updated. This has nothing to do with the
solution to the problem and everything to do with avoiding the impact.
For example, I have 3 other devs that work with VSCode using XDebug and the
Becker PHP Debug extension, so once I knew the problem and work around, I
altered my colleagues to avoid any impact.
Please don't take this as ingratitude as I'm grateful for this thread and
the solutions provided, I was just wondering if there is a way to push this
information to those who might need it.
I realize this is part and parcel of CI, with so many moving parts, sooner
or later things are bound to get out of sync, perhaps a push or billboard
solution might avoid impact.

On Wed, Dec 16, 2020 at 10:25 PM Andre Weinand [e-mail]
wrote:

Two clones of this extension have already fixed the issue.
Please see this comment: #424 (comment)
https://github.com/felixfbecker/vscode-php-debug/issues/424#issuecomment-727932756

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/felixfbecker/vscode-php-debug/issues/424#issuecomment-747047705,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARYOIOR2DLUWFICULTOPETSVEQVJANCNFSM4TSDUFPQ
.

[stevewh]

Perfect Julian, now only if we could keep this sticky at the top of the
thread, minimal impact.

On Wed, Dec 16, 2020 at 10:56 PM Julian Calaby [e-mail]
wrote:

We seem to be re-treading a lot of the same ground here.

For those who got here late, please read the comments before commenting.

To summarise:

• @felixfbecker https://github.com/felixfbecker has apparently
  abandoned this extension, so expecting an update from him is probably
  unrealistic
• The simplest solution is to enable breakpoints everywhere: #424
  (comment)
  https://github.com/felixfbecker/vscode-php-debug/issues/424#issuecomment-743458417
• A "better" solution is to switch to one of the two forks in the VSC
  repository. I switched to the Tiansin one as the other one (the "Chinese"
  one) didn't work for me:
  https://github.com/tiansin/vscode-php-debug.git

Actions from here are either:

1. @felixfbecker https://github.com/felixfbecker flags this as
   abandoned and passes the torch to one of the other extensions
2. @felixfbecker https://github.com/felixfbecker passes ownership of
   this repository to someone else so they can start sorting through the
   issues and PRs
3. VSC adds a workaround (either compatibility with ancient extensions
   or detection of ancient extensions and an offer to enable breakpoints
   everywhere)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/felixfbecker/vscode-php-debug/issues/424#issuecomment-747064770,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARYOIM6EKBFUTFTKMPBFLDSVEUHPANCNFSM4TSDUFPQ
.

[xpertbot]

@JulianCBC I am unsure if you noticed but @tiansen repo is a fork of the repo by @robberphex (the "chinese" one) and @tiansen hasn't touched the plugin since Aug 2019. My point is, If this is truly abandoned, we need to figure out if @felixfbecker can be contacted at all, so he can transfer ownership or let us know officially if this is abandoned.

I don't think splitting the community between this and another extension is the right idea, since this is such an important plugin for PHP Development on VSCode. My Fork is a quick fix for people that develop on multiple computers or manage a team, without having to manually change core plugin files, and I agree the fix for Global breakpoints is a good temporary fix ( I even announced that fix on the README of my Fork); but if we are sure @felixfbecker is MIA for the maintenance of this extension, I am willing to help maintain my current fork (I maintain other Open Source Plugins).

[JulianCBC]

@xpertbot I'm aware of the lineage of those two forks.

IMHO the community is already split: there's a significant number of developers using both of those forks, judging by the numbers in VSC.

The outcomes I'm looking for here are either to:

1. Flag this extension as abandoned and nominate an extension for the community to move to
2. Have someone take over this extension and keep the community "here"

I'm not advocating that we split the community _in the long term_ - however until we have some certainty from @felixfbecker we have to use a workaround: either use the setting in VSC or switch extensions, which _is_ a split, however IMHO that's a temporary split until we hear from @felixfbecker or something else is done.

[weinand]

The latest stable VS Code (1.52.1) has a workaround for the missing adoption of the removed API.

[derickr]

FWIW, I would be happy to host this on the github.com/xdebug organisation and manage access and Pull Requests, but I do not use this myself, nor am I interested in working on the code, but I am happy to make releases.

[AnrDaemon]

Thanks, @derickr , your generosity is much appreciated.

[felixfbecker]

@derickr thanks for the offer, it's a great idea to transfer it into the org. I think it would make a lot of sense as the README also contains help on how to set up XDebug and a lot of issues that are filed are often more related to config of XDebug. From the start I've always thought of this as a thin adapter for your debugger, which really does the heavy lifting 👏🏻
I personally do not use PHP at all anymore (personally or professionally) so I can't spend free time on development and triaging the mass of issues, but I'm happy to setup publishing/CI pipeline and dependency upgrade tooling and review & merge a high quality PR.

I haven't done this process before, but I think the first step needed would need to be for you to add me to the xdebug org so I can transfer the repo and give me enough permissions to setup the GitHub apps for it (e.g. Renovate).

[derickr]

Hi @felixfbecker, I have invited you. But I also don't know how to move a repository. I think you can do that at https://github.com/felixfbecker/vscode-php-debug/settings and transfer ownership.

[derickr]

If you want, reach out through DM on Twitter @derickr to make this go smoother.

[derickr]

@felixfbecker I think you have access now to transfer the repository. I'll be away from my computer for a few days though to accept it.

[isidorn]

Thanks a lot for updating php-debug.
I have removed the workaround on the VS Code side now and verified all works well with the latest php-debug version.