Change:
})) === true; } <del> private async _runTaskCommand(filter?: { type?: string; taskName?: string } | string): Promise<void> { </del> <ins> private async _runTaskCommand(filter?: any | { type?: string; task?: string }): Promise<void> { </ins> if (!this._canRunCommand()) { return; }

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: macOS Steps to Reproduce: tasks with Related discussion Source code
refs
from Are you asking to change the arg to instead of ?
Please don't spread panic and use bold and capitalized words. Also, don't use hypothetical statistics. Regarding your issue, the properties of your arguments you passed to the function are wrong. The property is , not .
are you the VSCode dev? What was the goal of this issue?
Your code depends on an undocumented implementation detail of this command. Now it standardizes and properly exposes its arguments, which is different from the old format.
Yes, this code has been working since 2017. Do you know in which version of VSCode API it was standardized?
Supported args are (the old way) | both of those work for me
Didn't work for me. Works well with any VSCode version from 2016 to 1.69.2 (including). When did you rename to the ? Does it mean that VSCode v1.70 will break PlatformIO?
where did you find that API? I've just checked the : typescript interface NpmTaskDefinition extends TaskDefinition { script: string; } The API has not been changed since the defined it. See
This is not an API change. It's just arguments that can be provided to the command
Described here
what are your thoughts here? Now we have 2 interfaces for “task” entity/definition. What is the benefit to maintain 2 of them and make things complex?

I even don’t say that existing extensions are broken with v1.70.
No, see the scheme for the latest stable 1.69 and "the old way": could you reopen this issue and implement it? Thanks in advance.
are you requesting that be changed to ? the old schema did not have a property either.
Sorry, I don't want to disturb people anymore in this thread. We will refactor our codebase to the legacy form and make the PlatformIO extension compatible with any VSCode versions. We don't know how it will affect the performance while searching for the matching tasks. We typically contribute 20-30 tasks depending on the user's project complexity. But! Being on the API side, I don't like introducing a new task definition. If you want to rename "undocumented" property, maybe, the better candidate is ? In this case, will be unified across VSCode's codebase. Yes, it was my typo, sorry. We got -based definition many years ago from Maybe, that was the workaround to something else. I don't remember all details. It was 201 or 2018.
do you have context for what Dirk did here or an opinion about this?
It looks like the run task command used to support taking an . The argument mentioned in this issue doesn't need to be explicitly supported because it was implicitly supported through the interface, which only requires a property: Now, the run task command doesn't support taking an . While this wasn't defined as API, it was used as such. Given that this has been stable for years, my opinion is that we should continue to support taking an . Details about how used to be supported: arg here gets passed to : checks if the looks like an then creates an identifier from it. This is where the from the original issue comes from. It is a property of the :
Thanks, and for keeping compatibility with existing extensions