text:
[Run][Plugin Manager] Support Community / non-core plugins

Is the plugin environment the same as with Wox? The Wox.Plugin package seems to still be present. Can existing wox plugins be used? I can't drag any files into the launcher like I could with wox.
Do you have any guides or tips for creating a plugin otherwise?

right now we haven't tested that path.  is there a plugin you want enabled?  would be good to know what some of everyone's favorites are so we can validate.

I’m experimenting with developing my own extensions. I managed to get it working with Wox and it seems that PowerToys Run is using a very similar system. I tried compiling my extension and mimicking the other extensions by placing the folder with the other plugins C:\Program Files\PowerToys\modules\launcher\Plugins however the launcher isn't starting up.
I'm seeing this in the logs:
2020-05-19 20:44:03.4743|ERROR|PluginConfig.GetPluginMetadata|Didn't find config file <C:\Program Files\PowerToys\modules\launcher\Plugins\Wox.Plugin.TimeChecker\plugin.json>

I could try to contribute some plugin installation support if this hasn’t been looked into yet.

right now it is disabled so we can stabilize the core.  Else debugging could get progressively hard if we can't account for the base with people

right now we haven't tested that path. is there a plugin you want enabled? would be good to know what some of everyone's favorites are so we can validate.

everything search would be the must have for me including configuring indexed locations etc (even if this is done through everything itself like the wox integration)

Some of us would appreciate an instant translation plugin, like Gtranslate.

I personally would appreciate default browser's bookmark search. From what I remember when I was using Wox, their various bookmark search plugins were not efficient. Chromium's own omnibox is an excellent tool for bookmark searching.

I would personally really like the ability to convert between units, for example, to convert from imperial to metric.

Lorem Ipsum Generator would be awesome

Would also be great to convert currencies

Am also hoping to see plugins soon! This would allow developers to focus more on core features and leave stuff like integrated search #3245 and translate to the plugin creators.

right now it is disabled so we can stabilize the core. Else debugging could get progressively hard if we can't account for the base with people

So this means we can enable it and compile it ourselves?

In theory, if the plugins go against the plugin interface, it should work. I know we may have tweaked the interface however from the wox

I would also appreciate plugins support as I find Powertoys Run fast and well-designed but I've moved temporarily to Listary due to their extensibility, e.g. you can setup shortcut and url with placeholder {query} which is replaced so we can fast query nearly all pages like google, bing, filmweb, imdb, etc.

Devdocs or Zeal or something similar would be great.
Maybe custom web search providers

Adding a reference to https://github.com/microsoft/PowerToys/issues/5273

I would love to see Steam, Clipboard History, Youtube Query and an integration for the markdown note-taking tool Obsidian.

I would love to see Steam, Clipboard History, Youtube Query and an integration for the markdown note-taking tool Obsidian.

I would like to use Kitty.
https://github.com/Wox-launcher/Wox.Plugin.Kitty

I would like to use Kitty.
https://github.com/Wox-launcher/Wox.Plugin.Kitty

+1 I'd like to have a google/bing search plugin sort of g searchquery or b searchquery :)

+1 I'd like to have a google/bing search plugin sort of g searchquery or b searchquery :)

support search devdocs

@elonzh

support search devdocs

Create a separate issue for it so we can discuss it there.

Throwing in a request for a plugin to launch Control Panel applets (Sound, Device Manager, etc) directly from Run as well (kind of like Windows/Cortana search already do).

I can not search the "add or remove programs". Could we add 1 more feature like that please? Thank you so much!

Any update on this?

Any update on this?

Don't have a lot of updates on it. Currently, the only way is to include a plugin in this repository. We created a checklist for reviewing purposes. You can also use it as requirements for the new or ported from wox plugins.

Hello,
I have create a plugin for generic calculations, units conversion, timezones etc in python and recently ported it to Windows and I was thinking to "connect" it to Wox, but I prefer PowerToys Run for my Windows tasks.
Is there any future plan to allow plugins in Python like Wox and not only C#/C++?

Is there any future plan to allow plugins in Python like Wox and not only C#/C++?

@dedavis6797, I guess it is a post stabilization milestone.

This is wild that this is not planned. If you guys were on uservoice this would be #1. This will be what builds a community around this tool.
Who is setting the strategy for this tool?

Hi @bwt615.  I'm one of those people. This has implications to officially support a model we're not currently ready to take on.  Right now we're prioritizing other items. PT Run is actually fully plugin based so you could do this right now if you wanted to.  Adding this style functionality formally has a lot of larger scale engineering efforts that would have to be done.
https://github.com/microsoft/PowerToys/wiki/Roadmap is where we are currently thinking about.  Don't worry, this is something that is top of mind for us.

I developed a few plugins for Wox of my own using node, to handle translation, definition, journaling, creating guids. Wox allowed using external binaries through JSONP on stdin/stdout, which truly would be the way to enable anything possible in PT run. Would be more than glad to have a look at pushing a PR for that if there's a chance that it gets merged.
I'd also consider porting my plugins to .net if there's an official doc for extensibility, but I can't find that.
Custom plugins is a must that prevents me from moving from wox to PT run

Hi @bwt615.  I'm one of those people. This has implications to officially support a model we're not currently ready to take on.  Right now we're prioritizing other items. PT Run is actually fully plugin based so you could do this right now if you wanted to.  Adding this style functionality formally has a lot of larger scale engineering efforts that would have to be done.
https://github.com/microsoft/PowerToys/wiki/Roadmap is where we are currently thinking about.  Don't worry, this is something that is top of mind for us.

I think you'd find people would be happy to sign off on this being unsupported. If you guys were on uservoice this would be up top.

If the plugin library Wox.Plugin is published from this repo, it would be possible for developers to build plugins externally. The currently published version of Wox.Plugin does not support netcore 3.1. Is this something that could be done?

I mentioned above that I wanted to make a contribution in relation to plugin support. I have recently been able to spend some time on this.
I have been trying to see if the existing plugins from Wox can run on an installed version of PowerToys. I have a sample plugin I used for a tutorial I made a few years ago for creating and installing plugins for the Wox launcher. The plugin uses the package Wox.Plugin 1.3.159 which is no longer maintained. I made some changes to the plugin to match the format and layout of the plugins on PowerToys.
Running PowerToys gave me this error:

A stack trace popped up saying the Wox.Plugin.dll  couldn’t be found. I couldn’t get it to reappear though so I can’t send the trace. I believe this is because the outdated package is on .NET Framework and PowerToys is expecting Core 3.1
I removed the NuGet reference to the package in my project file and added a local reference to the updated dll from this repo. This worked and it runs like it did with Wox.

I would like to contribute to PowerToys by adding support to install plugins to the launcher without the need for a dev to add it to the PowerToys repo. A plugin developer wouldn’t need to deal with scary things like wix fragments and installers which is a nice bonus!
This would require publishing the updated version of Wox.Plugin. This would enable developers to create plugins like they did for Wox and potentially port some over. As PowerToys is for power users, I think it is reasonable to support installing and not distributing every plugin with the installer. I would be keen to document and make the overall developer experience for plugin developers good as I had many difficulties when developing for Wox.
I wanted to try and create a dotnet project template for a plugin project. There would also need to be a tool for installing the plugin and restarting PowerToys as I manually moved the files into the correct place. This could be a dotnet global tool or a part of the PowerToys application.
I have been hesitant to implement too much of this before I updated the team on what I have done. I wanted to develop some plugins for myself to start with so I was thinking with that approach during my spike. I published Wox.Plugin.Fork to try and consume the package while testing however I struggled to get it working as I didn’t want to change the build output folder and dotnet pack was not working as expected nor was adding the pack on build option to the csproj in Wox.Plugin. Publishing from this repo may need to use the name .Fork , I tried to follow convention with that.
When I consumed the package I was getting build warnings about .NET Framework, it looks like it is from the Interop package which I don’t fully understand. I was wondering if we could extract out the UI dependencies that have been added to the project. That way a package could be distributed that would only contain the plugin api, like the original package. PluginPair etc could be in its own project. I haven’t worked on the project until recently so there are many angles I’m missing however these were my initial thoughts.
Any guidance and suggestions would be really appreciated. I’m mindful that this is not in the roadmap so I would be ok with maintaining a third party plugin system on my fork if it cannot be prioritised or included.
I have found it challenging figuring out some things in the repo and would also be keen to help with making that easier for new contributors. I am keen to understand the build stuff in .pipeline, the docs only mention building with Visual Studio. I have quite a lot of questions and learnings from the spike but wasn’t sure if this was the right place to bring them up so I’ve skimmed over some details.
@crutkas I can create a new issue that has a spec which would go into more detail and clarify some points if the team thinks it’s ok?

Let's chat (crutkas@microsoft.com) & maybe let's create a more dedicated issue for how to pull this off and can migrate back here.  We'll be upgrading to .NET 6 shortly and i think Wox is still on .NET Fx.  We want a full break from .NET Fx so we can easily shift to ARM64.  Also I think we should think about Wox based derivates as well.  @jjw24 has a fork as well.  We actually based our fork off of his and i believe they are on .NET Core and up.
Re: Pipeline, i'd rather have someone focus on the core thing they are working on rather than integration.  Getting stuff hooked into the build system can be interesting.  0.53's shift will actually drastically make stuff simplier
FYI for time zone stuff: https://github.com/microsoft/PowerToys/pull/11431 via @TobiasSekan may be of interest

I mentioned above that I wanted to make a contribution in relation to plugin support. I have recently been able to spend some time on this.
I have been trying to see if the existing plugins from Wox can run on an installed version of PowerToys. I have a sample plugin I used for a tutorial I made a few years ago for creating and installing plugins for the Wox launcher. The plugin uses the package Wox.Plugin 1.3.159 which is no longer maintained. I made some changes to the plugin to match the format and layout of the plugins on PowerToys.
Running PowerToys gave me this error:
A stack trace popped up saying the Wox.Plugin.dll couldn’t be found. I couldn’t get it to reappear though so I can’t send the trace. I believe this is because the outdated package is on .NET Framework and PowerToys is expecting Core 3.1
I removed the NuGet reference to the package in my project file and added a local reference to the updated dll from this repo. This worked and it runs like it did with Wox.

I would like to contribute to PowerToys by adding support to install plugins to the launcher without the need for a dev to add it to the PowerToys repo. A plugin developer wouldn’t need to deal with scary things like wix fragments and installers which is a nice bonus!
This would require publishing the updated version of Wox.Plugin. This would enable developers to create plugins like they did for Wox and potentially port some over. As PowerToys is for power users, I think it is reasonable to support installing and not distributing every plugin with the installer. I would be keen to document and make the overall developer experience for plugin developers good as I had many difficulties when developing for Wox.
I wanted to try and create a dotnet project template for a plugin project. There would also need to be a tool for installing the plugin and restarting PowerToys as I manually moved the files into the correct place. This could be a dotnet global tool or a part of the PowerToys application.
I have been hesitant to implement too much of this before I updated the team on what I have done. I wanted to develop some plugins for myself to start with so I was thinking with that approach during my spike. I published Wox.Plugin.Fork to try and consume the package while testing however I struggled to get it working as I didn’t want to change the build output folder and dotnet pack was not working as expected nor was adding the pack on build option to the csproj in Wox.Plugin. Publishing from this repo may need to use the name .Fork , I tried to follow convention with that.
When I consumed the package I was getting build warnings about .NET Framework, it looks like it is from the Interop package which I don’t fully understand. I was wondering if we could extract out the UI dependencies that have been added to the project. That way a package could be distributed that would only contain the plugin api, like the original package. PluginPair etc could be in its own project. I haven’t worked on the project until recently so there are many angles I’m missing however these were my initial thoughts.
Any guidance and suggestions would be really appreciated. I’m mindful that this is not in the roadmap so I would be ok with maintaining a third party plugin system on my fork if it cannot be prioritised or included.
I have found it challenging figuring out some things in the repo and would also be keen to help with making that easier for new contributors. I am keen to understand the build stuff in .pipeline, the docs only mention building with Visual Studio. I have quite a lot of questions and learnings from the spike but wasn’t sure if this was the right place to bring them up so I’ve skimmed over some details.
@crutkas I can create a new issue that has a spec which would go into more detail and clarify some points if the team thinks it’s ok?

is the modified version of the plugin available on github too?

@dewinterjack did you just put your plugin in C:\Program Files\PowerToys\modules\launcher\Plugins then?

@dolphin-cat The modified plugin is not on GitHub as this was a spike. I can push the change to a branch on my fork however the goal is to use a less hacky approach.
The change that worked was modifying the csproj of the plugin to point to the new dll instead of the nupkg. I will provide more context when I create the separate issue.

@dewinterjack did you just put your plugin in C:\Program Files\PowerToys\modules\launcher\Plugins then?

Yes, along with the wox dll

@dewinterjack - cool, I'll see if I can port some of my plugins then :)

I will post some more details once I have spoken with the team about it. In the meantime feel free to contact me with any questions @skttl - jackdewinter1@gmail.com

Yay 🥳

I had to add some properties from the supplied plugins plugin.json file, like IsGlobal, IcoPathDark and IcoPathLight. Not sure which of those are required.
Also recreated the project as netcoreapp3.1 - but that was before figuring out the needed changes to plugin.json.

Let's chat (crutkas@microsoft.com) & maybe let's create a more dedicated issue for how to pull this off and can migrate back here. We'll be upgrading to .NET 6 shortly and i think Wox is still on .NET Fx. We want a full break from .NET Fx so we can easily shift to ARM64. Also I think we should think about Wox based derivates as well. @jjw24 has a fork as well. We actually based our fork off of his and i believe they are on .NET Core and up.

Hi @crutkas, since there are other priority items happening I was going to wait for when you guys are ready to take on the community plugin support to start the conversation.
The team and myself at Flow Launcher would be quite interested to discuss how we can allow the community to build plugins that are fully compatible for both PT Run and Flow Launcher. We are currently on .Net 5 so 6 would not be difficult to upgrade to.
Perhaps a dedicated issue to further this discussion when ready.

@dolphin-cat The modified plugin is not on GitHub as this was a spike. I can push the change to a branch on my fork however the goal is to use a less hacky approach.
The change that worked was modifying the csproj of the plugin to point to the new dll instead of the nupkg. I will provide more context when I create the separate issue.

i put the timechecker plugin from your github on the plugins folder and powertoys didn't find it, can you tell me how to load a plugin? i am interested in making one
could you add like a "powertoys" branch or a different repo with the modified version you managed to get to work?

also plugin manager is broken

Oh no, upgrading to 0.53.1 broke my Guid plugin :( I wonder what changed.

Yay 🥳
I had to add some properties from the supplied plugins plugin.json file, like IsGlobal, IcoPathDark and IcoPathLight. Not sure which of those are required. Seems like it's IcoPathDark and IcoPathLight.
Also recreated the project as netcoreapp3.1 - but that was before figuring out the needed changes to plugin.json.

how did you do it? can you post the code somewhere on your github?

@dolphin-cat code is up here: https://github.com/skttl/ptrun-guid

I would love for the search to optionally include favorites, like the Ueli plugin does...

@crutkas - any update on this? see multiple other issues around the same...

I was able to create a PowerToys Run plugin from the discussion in this issue 🎉
Thanks for sharing your knowledge 🙏
GEmojiSharp.PowerToysRun

GitHub Emoji PowerToys Run plugin

Documentation
Source

Since this seems to have become a feature request issue for plugins, I'd like to throw in a request for Everything which seems to have been implemented by Wox as well.
This one would be awesome

@crutkas I'm wondering if it's be possible for Powertoys to create a nuget package? I think that'd be easier for 3rd party developers, since we don't really need the whole PT repo to compile, just the key dll's.

@PauloDanielCarneiro not sure if you know by now, but I've already made the Everything plugin here

@lin-yvc, yes that is a good idea but we're still doing deep thinking on this.  We still need to validate how stuff would work like, if we move to 0.62 and you are on .58, what happens.

Is this still the right place to discuss support for custom (user-written) plugins? The issue seems to have diverged into many separate topics, and I'm having a hard time being sure.
In particular:

Is there (still) an intention to support Wox-style plugins written by the user?
Will this include the ability to write plugins in Python, as Wox allows? Having to write a compiled C# DLL for any plugin seems like a relatively high barrier.
Is there any tracking item I can follow which better summarises progress towards having custom plugins?

Maybe one day they’ll accept that this is the most in demand feature :)
[https://i.imgur.com/zf87pbX.jpg]
Benjamin Wesley Thomas
m +1 (781) 864-3648 | f +1 (781) 787-2609
e @.***<file:///private/var/mobile/Library/Mobile%20Documents/com~apple~CloudDocs/iOS%20Signatures/EmailSignature1.html#>
w www.benjaminwesleythomas.com<file:///private/var/mobile/Library/Mobile%20Documents/com~apple~CloudDocs/iOS%20Signatures/EmailSignature1.html#>
[https://i.imgur.com/LekBgmL.png]https://twitter.com/benjaminwthomas [https://i.imgur.com/lyRQWJR.png] https://www.linkedin.com/in/benjaminwesleythomas/

From: Paul Moore @.>
Sent: Thursday, June 9, 2022 7:02:23 AM
To: microsoft/PowerToys @.>
Cc: Benjamin Thomas @.>; Mention @.>
Subject: Re: [microsoft/PowerToys] [Run][Plugin Manager] Support Community / non-core plugins (#3200)
Is this still the right place to discuss support for custom (user-written) plugins? The issue seems to have diverged into many separate topics, and I'm having a hard time being sure.
In particular:

Is there (still) an intention to support Wox-style plugins written by the user?
Will this include the ability to write plugins in Python, as Wox allows? Having to write a compiled C# DLL for any plugin seems like a relatively high barrier.
Is there any tracking item I can follow which better summarises progress towards having custom plugins?

—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/PowerToys/issues/3200#issuecomment-1150980586, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALRHQ3KGTQAUOUC3MMRPUELVOHFL7ANCNFSM4NFJDGUA.
You are receiving this because you were mentioned.Message ID: @.***>

@bwt615 we do actually validate top requests. Example: arm64 was one of the top features and we delivered that :)
this is a complex feature and has long term effects. In past releases we would have had multiple breaking changes for plugins due to fundamental upgrades.

@bwt615 we do actually validate top requests. Example: arm64 was one of the top features and we delivered that :)
this is a complex feature and has long term effects. In past releases we would have had multiple breaking changes for plugins due to fundamental upgrades.

It could be added an experimental API with warnings telling people that it might break plugins in future updates, but it will give the devs the ability they want.

@PauloDanielCarneiro the system is already a plugin system, nothing is preventing someone from doing what you're outlining.  There is a WSL Distro and a Everything plugin already.

Oh, sorry. By bad.Is there some basic documentation about how to work with it?

Oh, sorry. By bad.
Is there some basic documentation about how to work with it? Could not find it... i.i

I agree about disclaimers along with documentation! Both would go a long way.
@crutkas would be great to get transparency into the data about top requests. I feel MSFT directionally supports this with them exploring uservoice like options.

We use github as one of the sources.  We leverage comment count, cross reference, duplicates, reaction counts as well as other internal signals for what our core team focuses on. Everything has trade-offs so stuff is an art, not a science. I have a long post in this thread also about a lot of the considerations to have a proper 'supported' plugin model.
Dev docs: IMO best way is to look at how some of the existing code works for other plugins.

https://github.com/microsoft/PowerToys/blob/main/doc/devdocs/modules/launcher/
https://github.com/microsoft/PowerToys/blob/main/doc/devdocs/modules/launcher/plugins/
https://github.com/microsoft/PowerToys/blob/main/doc/devdocs/modules/launcher/plugins/overview.md

We 100% accept pull requests as someone just submitted one for instance on OneNote.

I'm wondering if there's anymore progress on this? or is it simply still a very community oriented without any clear consolidation?
It'd would be nice if the following could happen:

[ ] nuget package for PTRun to decrease the barrier to entry for development
[ ] plugin store, or at least consolidated list where people can find community plugins (this can maybe alleviate some of the constant duplicated feature requests)

[ ] ability to remove plugins (and persist over updates?)

[ ] apply plugin store/ modularizing idea to PowerToys functions so it's not just limited to PTRun (#22187 )

There's currently plugins of PowerToys (and Run) that I simply don't use/need, I can simply remove ununsed run plugin by deleting the folder of that plugin, but for Powertoys it's a different storry, it'll throw error on launch (PT still works fine tho).
But whatever I remove gets reinstalled after updates, so it'd be nice if they're all modularized and updates can "detect" what's not needed.
Regarding https://github.com/microsoft/PowerToys/issues/3200#issuecomment-1139941758, about community plugins/nuget package

if we move to 0.62 and you are on .58, what happens.

It can probably be handle brutally? just try to load it,

if there's no significant change to the code, it'll load just fine despite the version difference

if it fails, throw an error message, disable it and mark it for exclusion in future loading process (just like how it is now) until the version number of the plugin in settings.json changes

@crutkas Can we see the data on how this is not the most requested feature?
Product management best practices are transparency to roadmap and being "user" driven. I see none of these in PowerToys. I work very closely with your Cloud side of the house through my dayjob and started giving them a lot of my feedback about this - they say it is not at all the culture MSFT is trying to create.

@crutkas Can we see the data on how this is not the most requested feature?
Product management best practices are transparency to roadmap and being "user" driven. I see none of these in PowerToys. I work very closely with your Cloud side of the house through my dayjob and started giving them a lot of my feedback about this - they say it is not at all the culture MSFT is trying to create.

I am in the process of starting my own MSP and leaving my day job. We are honestly considering going all mac due to the lack of a good launcher on Windows. This lack of support is definitely going to have some impact on Windows sales. I'm being very verbal about this on social media - think you should really reflect on this a bit.

@crutkas Can we see the data on how this is not the most requested feature?
Product management best practices are transparency to roadmap and being "user" driven. I see none of these in PowerToys. I work very closely with your Cloud side of the house through my dayjob and started giving them a lot of my feedback about this - they say it is not at all the culture MSFT is trying to create.

I am in the process of starting my own MSP and leaving my day job. We are honestly considering going all mac due to the lack of a good launcher on Windows. This lack of support is definitely going to have some impact on Windows sales. I'm being very verbal about this on social media - think you should really reflect on this a bit.

While all of us subscribed (34 users at the moment, and 54 reaction emojis) would like to see this feature, your level of self-entitlement is beyond measure. Not only do the tiniest of fractions of Windows user base even know PowerToys exists, even fewer of those people in subset use the Run plugin. Even fewer of whom need more behaviors than are already included by the existing plugins. Nearly all windows users are content to launch with the start menu, so I think they are not too worried about this bug impacting their sales figures nor should they be.
Repeated comments on issues like this such as your two back-to-back ones above are counter-productive and only serve to spam those of us subscribing to the issue and bring nothing of value to the conversation. If you wish to add a "me too" or "+1" to a GitHub issue just subscribe and/or add a 👍 to the issue.
If the feature is so critical to you, you are welcome to implement it and submit a PR to the repository.
Feel free to perhaps look at Wox, the project this one is forked from which this feature is requested to follow from.

How to add plugins to the PowerToys Run?
How can I have currency conversion from the calc.exe in the Run app?

Hi!
I leave here two plugins that I have created. They have very basic functionality but can be useful in someone's daily workflow.

Search Microsoft Edge favorites: https://github.com/davidegiacometti/PowerToys-Run-EdgeFavorite
Search GitKraken repositories:  https://github.com/davidegiacometti/PowerToys-Run-GitKraken

I am not a coder so seeking community help than building. Is it possible to add a custom unit conversion feature to the PowerToys Run Unit Converter plugin?  Have used keypirinha-cvt plugin for many years and there is no equivalent low-code option in PowerToys to do the same. Couple links on topic from history of Cvt plugin development -

Custom conversions beyond in tool - https://github.com/DrorHarari/keypirinha-cvt#customizing-conversions
Basics of custom units - https://github.com/DrorHarari/keypirinha-cvt#adding-new-conversions-measures
Discussion on custom calculations with examples - https://github.com/DrorHarari/keypirinha-cvt/issues/4

Perhaps can seek help from @DrorHarari

I tried making a feature request, but apparently there is no plans for getting this into Run by default, so I copy/paste it into here to see if anyone would like to make it into a plugin :)
Being able to search on different sites would be a very welcome feature. Not sure if Chrome have this, but Vivaldi at least have this feature where you can set it up so if I in the address field write "yt Rickroll" (without the "") you'd search for Rickroll on Youtube, "map Paris" you'd search for Paris on google maps or "wiki super mario" you'd search for super mario on Wikipedia.
This would just be a list where you can add you're own site URL for searching with a suggestion URL and whatever abbreviation you'd want with it.
Below is a screenshot on how I've set it up in Vivaldi.

After some scrolling through this thread I see that I'm not alone in asking for this particular functionality so getting this would make more than one person happy :)
I did some searching did find a plugin that you can search on IMDb (with suggestions) directly from Run which is awesome. Then I started to think if it would be possible to use the code from that plugin to do the same for other places as well, and maybe even expose the search URL and suggest URL directly in the plugin settings. This way it would be an easy deal to at least duplicate that plugin with different settings for each site I want to be able to search on, or maybe for a way more elegant solution just give the possibility to add more than one site with a shortcut for each  directly in the plugin, just like this Vivaldi list above :)
I did have a quick peak myself in the IMDb plugin source code, but me having only dabble every so slightly in python or even programming was quite lost. So hoping someone else with a bit more skills could help out? :)

I and many community members could not do currency conversion in Powertoys Run. I have been through other discussions which discuss this in more detail. I took the liberty to create a custom plugin that does this. It is available here: https://github.com/Advaith3600/powertoys-run-currency-converter

Do you have any guides or tips for creating a plugin otherwise?

I took the time to write a blog post on the subject:

https://conductofcode.io/post/creating-custom-powertoys-run-plugins/

Creating custom PowerToys Run plugins
A step by step guide on how to create community plugins for PowerToys Run

I would also appreciate plugins support as I find Powertoys Run fast and well-designed but I've moved temporarily to Listary due to their extensibility, e.g. you can setup shortcut and url with placeholder {query} which is replaced so we can fast query nearly all pages like google, bing, filmweb, imdb, etc.

@Drabenstein

Being able to search on different sites would be a very welcome feature. Not sure if Chrome have this, but Vivaldi at least have this feature where you can set it up so if I in the address field write "yt Rickroll" (without the "") you'd search for Rickroll on Youtube, "map Paris" you'd search for Paris on google maps or "wiki super mario" you'd search for super mario on Wikipedia.
This would just be a list where you can add you're own site URL for searching with a suggestion URL and whatever abbreviation you'd want with it.

@Gurrrra
I created a plugin that lets you search sites with DuckDuckGo !Bangs

https://github.com/hlaueriksson/Community.PowerToys.Run.Plugins#bang

I think it's something along the lines of what you described in your comments above.

Hey guys, I implemented "select a site to search" in my plugin. I think a lot of people need this feature.

@crutkas I'm wondering if it's be possible for Powertoys to create a nuget package? I think that'd be easier for 3rd party developers, since we don't really need the whole PT repo to compile, just the key dll's.

I took the matters into my own hands and created:

https://github.com/hlaueriksson/Community.PowerToys.Run.Plugins.Dependencies

that builds and published a NuGet package to:

https://www.nuget.org/packages/Community.PowerToys.Run.Plugins.Dependencies

I have tried this approach here:

https://github.com/hlaueriksson/GEmojiSharp/commit/759bfd0a5265b91880bf8aa9216f08992fa54700

and it builds:

https://github.com/hlaueriksson/GEmojiSharp/actions/runs/10044460509

Example of usage in a .csproj file:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
    <Platforms>x64;ARM64</Platforms>
    <PlatformTarget>$(Platform)</PlatformTarget>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Community.PowerToys.Run.Plugins.Dependencies" Version="0.82.1" />
  </ItemGroup>

  <ItemGroup>
    <None Include="plugin.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Include="Images/*.png">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
  </ItemGroup>

</Project>

authors: ABS96 Advaith3600 Animeshz CWempe ChrisKoenig Daydreamer-riri Dhruva-Storz Drabenstein Gurrrra PauloDanielCarneiro SangNguyen2810 addrum bwt615 calania cfe84 cobrabr crutkas davidegiacometti dewinterjack dlgombert dolphin-cat drew-royster eiis1000 elonzh enricogior gmmedia gtheys hlaueriksson janeoa jjw24 kariudo lin-ycv mykhailopylyp niklasbuesing pfmoore phone8588 siddboketto skttl tchar


text:
PowerToys General Settings

Environment
Windows build number: Version 10.0.18363.836
PowerToys version: 0.18.1
PowerToy module for which you are reporting the bug (if applicable): General tab

Steps to reproduce
Choosing General tab in left hand column.
Expected behavior
The previous version of PowerToys had "General Settings," rather than just "General." You could see a list of "Available PowerToys," with on/off toggles, and overviews. It was a nice way to see all options, without clicking on each individual PowerToys tabs to the left.
Actual behavior
The General tab only shows general settings, now.
Screenshots
This is what it used to look like . . . (I grabbed this off the File Explorer Preview module)

Things change. And even though I haven't used any of the earlier version, I agree with this change.

Hi @OkieInCO
thank you for you feedback.
The change is by design and there are several reasons that make the new UI better, including the fact that is was incoherent that you had to switch between the module setting and the general settings to turn on/off/change settings for a module.
There is an open issue for adding a visual feedback on which modules are on and which are off, but we won't move back the individual on/off switches to the general page.

Thank you for the quick reply. Makes sense.

source: gharchive/issue

authors: Jay-o-Way OkieInCO enricogior

repo: microsoft/PowerToys

license: MIT

license_type: permissive

license_source: github-api


text:
PowerToys Run Bug report - Bug unknown

Microsoft PowerToys version
0.87.1.0
Installation method
WinGet
Running as admin
No
Area(s) with issue?
PowerToys Run
Steps to reproduce
I don't know what happened or what is the issue. I just got a message encouraging to submit a report.
This is the log displayed:
Version: 0.87.1.0
OS Version: Microsoft Windows NT 10.0.26100.0
IntPtr Length: 8
x64: True
Date: 12/22/2024 2:10:01 PM
Exception:
System.Windows.Markup.XamlParseException: Set property 'System.Windows.ResourceDictionary.DeferrableContent' threw an exception.
---> System.ArgumentException: Item has already been added. Key in dictionary: 'SystemColorWindowColorBrush'  Key being added: 'SystemColorWindowColorBrush'
at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add)
at System.Windows.ResourceDictionary.SetKeys(IList`1 keyCollection, IServiceProvider serviceProvider)
at MS.Internal.Xaml.Runtime.ClrObjectRuntime.SetValue(Object inst, XamlMember property, Object value)
--- End of inner exception stack trace ---
at System.Windows.Markup.XamlReader.RewrapException(Exception e, IXamlLineInfo lineInfo, Uri baseUri)
at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri)
at System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream)
at System.Windows.Application.LoadBamlStreamWithSyncInfo(Stream stream, ParserContext pc)
at MS.Internal.AppModel.AppModelKnownContentFactory.BamlConverterCore(Stream stream, Uri baseUri, Boolean canUseTopLevelBrowser, Boolean sandboxExternalContent, Boolean allowAsync, Boolean isJournalNavigation, XamlReader& asyncObjectConverter, Boolean isUnsafe)
at System.Windows.ResourceDictionary.set_Source(Uri value)
at System.Windows.ThemeManager.GetThemeDictionary(ThemeMode themeMode)
at System.Windows.ThemeManager.OnSystemThemeChanged()
at System.Windows.SystemResources.SystemThemeFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
✔ Expected Behavior
No response
❌ Actual Behavior
No response
Other Software
No response

/dup #36389


text:
Window moving, resizing, bring to top, send to back by grabbing any part of the window

Back when I used FVWM2 it had some super flexible key + mouse bindings that made working with windows amazingly efficient . It'll be good to see something similar in Windows 10. The ones that were particularly useful were:

Shift keys + click any part of a window to bring it to top.
Shift keys + click any part of a window to send it to back.
Shift keys + click-drag any part of the window to move it.
Shift keys + click-drag near the window edges to resize it.

The shift keys (ctrl, alt, shift and/or win) were configurable as well as the mouse button. Personally I found it useful to have the same shift key combinations and the left mouse button for all of these actions, except (2) used the right mouse button. The grab area in (4) was configurable, so one could grab any pixel within 10 pixels from the edge or 100 pixels from the edge to resize the window.
What make these actions useful for working efficiently is that one can keep their focus on working when they shuffle around the windows. It may not feel like it takes a lot of effort to resize a window, but trying to grab just the right pixel in the middle of concentrating on work is just annoying enough that it can break one's concentration. Sending window to the back is especially great if one is working with a maximized window and need to quickly reference another window "somewhere in the upper-left corner in the the back of the maximized window among lots of other windows". I found it more visually intuitive than alt-tab when looking for the window that I know is placed in a certain position in the back.

shift+click already has a function, which is to select all items in a list of items (such as files in Explorer) between the first click and the second, so it couldn't be in any part of the window

By "shift keys" I meant the ctrl, alt, shift, win, or a combination of them. These keys are all referred to as shift keys - confusingly.

Oh really? Nevermind then... I'm not native so I assumed you were referring to the fact that there are 2 shift keys on every keyboard hehehe

What I meant by "shift keys" was ctrl, alt, shift, win, or a combination thereof. They're all called "shift" keys -- confusingly. Sorry I explained it later in my writeup. Obviously assigning a shift key combination that the application uses will be problematic so the combination should be configurable so the user can assign it to something they don't use in any application they use.

Just FYI, keys like Ctrl, Shift, Alt, etc are commonly known as modifier keys.

(dup with #269?)

Window centering too (I use it from AltDrag, like alt gr + left click on the window = center it on screen)

Already a PR

/dup https://github.com/microsoft/PowerToys/issues/269

authors: StrScr TroudhuK avivey bergamin child-duckling crutkas markuskimius


text:
[Run] Add options to run commands from different shells (in Settings or at runtime)

EDIT: Settings are one aspect of this feature, also see https://github.com/microsoft/PowerToys/issues/9627 for a way to select different shells at runtime. We need to make sure the UX is consistent between settings and runtime.

Add settings to select default shell and terminal which will affect PowerToys Run. It should also detect third-party terminals as suggested in the spec:

11
Users   can see third-party terminals in the dropdown list for default terminal
3

First thing I tried to do when using Run for the first time

0.681 Which option can specify shell 0.681?  Can't see where you can set in Powertoy Run

Hello, I have submitted a proposal for adding WindowsTerminal as an Execution Shell option in the config. I have been daily driving the changes for a week and it works great. It would be great if someone could take a look at the PR. Thanks.
https://github.com/microsoft/PowerToys/pull/25661

This has been worked on for the 0.74.0 release. Please update PowerToys to the latest version. 😉
https://github.com/microsoft/PowerToys/releases

Great feature. Thanks for implementing this. Would be great to add support for WSL.

authors: cool-delete jaimecbernardo jyuwono pgeng-nv phoenix172 shellwhale


text:
[FZ Editor] Merging zones causes many bugs

Environment
Windows build number: Microsoft Windows [Version 10.0.19041.329]
PowerToys version: v0.18.2
PowerToy module for which you are reporting the bug (if applicable): FancyZones

Steps to reproduce

Set your window spacing to an extreme number like 100 or 150 (it doesn't have to be this extreme, but this is for demonstration purposes)
Set your number of windows to 2 (this might not be necessary)
Select the column layout and edit it
Split the left column horizontally, then merge the two pieces
The splitter preview is now incredibly buggy and snaps to the center of the two columns
Split either column off-center
Save the layout
Change the window spacing back to 0 and save
The panes are now all touching except there's still 100/150 spacing on the bottom

Expected behavior
The splitter shouldn't snap to the center after a merge when it didn't do so before the merge, and the bottom spacing should not be maintained when changing the window spacing.
Actual behavior
After a merge, the splitter snaps to the center and the spacing on the bottom cannot be removed.
Screenshots

@Aplet123
I haven't been able to reproduce this specific bug, but we are aware of the many problems of the current design of the layout data.
We already proposed to change it to avoid those problems https://github.com/microsoft/PowerToys/issues/5027
We also track the fact that this problem can cause a crash in https://github.com/microsoft/PowerToys/issues/9540 or invalid data https://github.com/microsoft/PowerToys/issues/9419
Closing this issue in favor of the other.


text:
[Peek] Add Audio Previewer

Summary of the Pull Request
Add a new previewer that support audio files into Peek.

PR Checklist

[x] Closes: #25989
[ ] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[ ] Tests: Added/updated and all pass
[x] Localization: All end user facing strings can be localized
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments
This uses  file thumbnail to render the artwork and this choice could lead to unexpected behavior if users have different thumbnails on their system.
TODO

[x] Need WinAppSDK 1.5: https://github.com/microsoft/microsoft-ui-xaml/issues/916

Validation Steps Performed

Tested all the file extensions using sample files downloaded from the internet
Tested reaction to OS theme/accent change
Tested play/pause using space bar

We should show the format after the length. What do you think?

We should show the format after the length. What do you think?

The idea was to focus on audio related properties. Does it make sense?
This also have  the same tooltip used for images and videos with secondary info.

We should show the format after the length. What do you think?

The idea was to focus on audio related properties. Does it make sense?

Yes, it does.

Still a draft, so I've removed the label to revisit on 0.80 :)

Reviewed the PR and re-tested with all the file extensions: It's ready for review.

/azp run

Woow.. 😞
I can reproduce it also on 0.79.0 with Monaco and default previewer but I can't get what's going on.
I have noticed that it's not only the button but also the red area doesn't allow to drag the window.

It disappear after maximizing/restoring the window and it doesn't seems to affect Images 😮

I have pushed a work-around for the first Peek activation.
The problem is related to the code that "create" the draggable area of the custom title bar: it doesn't work well with the collapsed button (no default app to open the previewed file).
Note that the issue isn't fully fixed since also in 0.79, while navigating from a file to a folder, a non draggable area could be found in the button location (now hidden).
Hope this is clear! 😅

I have reverted the UpdateDragRegion change.
I have ready another PR that try to completely address the issue.

source: gharchive/pull-request


text:
[Advanced Paste] Online AI models GPO

Summary of the Pull Request

PR Checklist

[ ] Closes: #xxx
[ ] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[ ] Tests: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

@stefansjfw
I am sure this is #32947. You are faster than I 😅.
As the primary usecase is to block usage of ai features we should nane it so. This is a well known doing in Windows and other tools. So lets call it "Disable AI ...." with default to "not configured" and "GPO enabled=No AI" and "GPO disabled/not configured=User can enable".

Don't forget to update the docs on https://learn.microsoft.com/en-us/windows/powertoys/grouppolicy .

The Utility table for the main policy.
Add a new block like we have for PT Run for the AI GPO.

@stefansjfw I am sure this is #32947. You are faster than I 😅.
As the primary usecase is to block usage of ai features we should nane it so. This is a well known doing in Windows and other tools. So lets call it "Disable AI ...." with default to "not configured" and "GPO enabled=No AI" and "GPO disabled/not configured=User can enable".

@htcfreek , We're basing this off on another setting we have there, which is "Allow experimentation". And also on the OS like the one that exists to allow clipboard history:

Did some fixes and updated with some images

@jaimecbernardo , @stefansjfw
Don't forget to update the GPO docs. Abd the utility enabled policy is also misding on the docs page.

authors: htcfreek jaimecbernardo stefansjfw


text:
Improve the 'report bug' functionality to auto-fill data

Summary of the Pull Request
!!! Important
For testing, please use the https://github.com/gokcekantarci/PowerToys/tree/BugReport-Autofill-Test-Branch branch. The updated bug_report.yml file is pushed to the forked repository main branch. Therefore this branch should be used for testing.
In this PR, some fields on the link opened with the 'Report Bug' button were automatically filled. When pressed the button from both the general page and the system tray, a bug report is created on the desktop. The fields that can be filled in on the page that opens later are filled automatically.

PR Checklist

[ ] Closes: #31797
[ ] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[ ] Tests: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

General Settings

System Tray

Validation Steps Performed
General Settings

Click the report a bug button on the general settings page and see the generating message box.
Wait for the process to finish and see the message generated. Then, check the report created with the report name in the message on the desktop.
Press the 'OK' button and wait for the bug report link to open automatically. Check that the version field and additional information field with the OS version, .NET version, Pref language, User locale, Installation, Run as admin fields are filled in correctly.
Press the report a bug button again. Cancel with the Cancel button before the report is created.
Check that the "https://aka.ms/powerToysReportBug" link opens automatically without filling in the relevant fields. Also check that no reports are being generated on the desktop.

System Tray

Press the report bug button from the system tray and see the generating notification message.
Wait for the process to finish and see the message generated. Then, check the report created with the report name in the message on the desktop.
Wait for the bug report link to open automatically. Check that the version field and additional information field with the OS version, .NET version, Pref language, User locale, Installation, Run as admin fields are filled in correctly.

Does it make sense to fill the PT version field or add it to the additional information?

Does this PR implements #28791? It looks like it does.

Should the "the file is created on the desktop" dialog open the desktop folder for you so you can attach it quicker? Now it requires the user to open File Explorer first, navigatw to desktop etc

it requires the user to open File Explorer first, navigatw to desktop etc

Ehm, normally the desktop can be only one click or hotkey away.

it requires the user to open File Explorer first, navigatw to desktop etc

Ehm, normally the desktop can be only one click or hotkey away.

It might, but why inform the user to go to navigate to a certain folder (which in my case has a lot of files and I'd need to manually search for it) if we could open it and highlight the file? E.g. using: https://stackoverflow.com/questions/13680415/how-to-open-explorer-with-a-specific-file-selected
Or at the very least provide a clickable link.
This is pretty common in confirmation dialogs in Windows apps when e.g. exporting a file like a video.

navigate to a certain folder

Well, the user can also minimize all windows to see the actual desktop (not as a folder). I think we're talking about a few second or clicks, but oh wel...
The idea to use Explorer with the file selected is actually fine. But then, why bother to ask? If a user creates the file, we can assume* they want to use it right away.
assume?
Said with a hint of sarcasm... I know assuming something is dangerous and often unwanted. But that doesn't seem to be a concern for Microsoft. Remember all the complaints about Windows 10 being installed without consent? Or importing data from Chrome into Edge. Or simply giving the user the choice between "Yes" and "Later" - where's the "No"? It's typical for Microsoft...

navigate to a certain folder

Well, the user can also minimize all windows to see the actual desktop (not as a folder). I think we're talking about a few second or clicks, but oh wel... The idea to use Explorer with the file selected is actually fine. But then, why bother to ask? If a user creates the file, we can assume* they want to use it right away.
assume?

I tried it as in the link suggested by @niels9001 https://stackoverflow.com/questions/13680415/how-to-open-explorer-with-a-specific-file-selected
I think opening both the link and the folder would create a bigger mess on the screen. The name of the file is specified in the last message. It will not be difficult to find this file on the desktop. So I think we need to move forward this way. If there are requests or complaints from users, we can easily add it.

/azp run

@gokcekantarci  did you resolve the feedback from @jaimecbernardo ?

authors: Jay-o-Way crutkas gokcekantarci htcfreek jaimecbernardo niels9001


text:
Clean up of Microsoft.ApplicationModel.Resources.PriGen.targets (round 4)

Remove more unused MSBuild code.
Microsoft.ApplicationModel.Resources.PriGen.targets was created from Microsoft.AppxPackage.targets where a bunch of appx generation MSBuild script code was removed (Microsoft.AppxPackage.targets does more than just PRI generation, which is all that we want Microsoft.ApplicationModel.Resources.PriGen.targets to do, as the name suggests). At that point though, not all non-PRI gen related MSBuild script code was removed. I'll now try to remove it over several rounds. This is round 4.
Round 1: #664
Round 2: #696
Round 3: #704
How verified
Used the MRTCore C# sample app and lib. Got rid of build outputs. Replaced the prigen targets file in the nuget package install with the one in this change. Built and ran the app.

is this needed?

Refers to: dev/MRTCore/packaging/Microsoft.ApplicationModel.Resources.PriGen.targets:111 in 9ba2918. [](commit_id = 9ba2918d4bf26ec6ffc218d0702b718f008c0903, deletion_comment = False)

this?

Refers to: dev/MRTCore/packaging/Microsoft.ApplicationModel.Resources.PriGen.targets:121 in 9ba2918. [](commit_id = 9ba2918d4bf26ec6ffc218d0702b718f008c0903, deletion_comment = False)

nope. i can get rid of it in the next round, if that's ok.

In reply to: 828027482

Refers to: dev/MRTCore/packaging/Microsoft.ApplicationModel.Resources.PriGen.targets:121 in 9ba2918. [](commit_id = 9ba2918d4bf26ec6ffc218d0702b718f008c0903, deletion_comment = False)

likely not. i need to look more carefully. i can get rid of it in the next round, if that's ok.

In reply to: 828027256

Refers to: dev/MRTCore/packaging/Microsoft.ApplicationModel.Resources.PriGen.targets:111 in 9ba2918. [](commit_id = 9ba2918d4bf26ec6ffc218d0702b718f008c0903, deletion_comment = False)

this is the 4th change of the cleanup. It becomes more difficult for next person trying to figure out what needs to be cleaned up. S/He needs to mentally merge all those changes together to get a full picture. Adding a few more just makes this worse.

In reply to: 828037384

Refers to: dev/MRTCore/packaging/Microsoft.ApplicationModel.Resources.PriGen.targets:111 in 9ba2918. [](commit_id = 9ba2918d4bf26ec6ffc218d0702b718f008c0903, deletion_comment = False)

/azp run

this is the 4th change of the cleanup. It becomes more difficult for next person trying to figure out what needs to be cleaned up. S/He needs to mentally merge all those changes together to get a full picture. Adding a few more just makes this worse.
In reply to: 828037384
Refers to: dev/MRTCore/packaging/Microsoft.ApplicationModel.Resources.PriGen.targets:111 in 9ba2918. [](commit_id = 9ba2918, deletion_comment = False)

removed more things in second iteration including the two things Hui asked for in comments

/azp run

repo: microsoft/ProjectReunion


text:
Multikey support

Great library, it was very exciting to actually run a simple homomorphic computation in my browser the other day with node-seal.
Does this project have any plans to support multikey homomorphic encryption, thus enabling secure collaborative computing? Various of the use cases that I'm interested in require multikey support.

Thanks for trying out SEAL! Extending to threshold or multi-key FHE is certainly in consideration. It's mostly a question of resourcing. I'll keep in mind your request as further evidence for the importance of this; maybe we can do it rather sooner than later.

Fantastic! And if it helps, I'm personally much more interested in multi-key over threshold, since I do not want to have to have all clients participate in a key generation event.

This was closed as completed, does that mean there is multi-key or threshold support now?

authors: kimlaine lastmjs

repo: microsoft/SEAL


text:
Transparent Ciphertext

Hello,
I am aware there have been issues reported on transparent ciphertexts, including #179 and #137. I also get the error of libc++abi.dylib: terminating with uncaught exception of type std::logic_error: result ciphertext is transparent when I do,
double p = 0.0046;
ckks_encoder.encode(p, ptext);
evaluator.mod_switch_to_inplace(ptext, ctext.parms_id());
evaluator.multiply_plain_inplace(ctext, ptext);

To avoid, I included two ifs in SEAL/native/src/seal/evaluator.cpp file like following:
void Evaluator::multiply_plain_inplace(Ciphertext &encrypted, const Plaintext &plain, MemoryPoolHandle pool)
{
        (...)
        if (encrypted.is_transparent())
        {
            continue;
        }
        if (plain.is_transparent())
        {
            continue;
        }
        // these two ifs are what I added

        if (encrypted.is_ntt_form())
        {
            multiply_plain_ntt(encrypted, plain);
            // Could not understand what ntt is.
        }
        else
        {
            multiply_plain_normal(encrypted, plain, move(pool));
        }

// I've also tried disabling the below #ifdef part, but same error occurs.
#ifdef SEAL_THROW_ON_TRANSPARENT_CIPHERTEX
        // Transparent ciphertext output is not allowed.
        if (encrypted.is_transparent())
        {
            throw logic_error("result ciphertext is transparent");
        }
#endif
}

However, the error is not reconciled.
FYI, my SEAL version is 3.5.6 (master), Apple clang version is 11.0.3, and cmake version is 3.13.4.
Does anyone know how to fix this problem?
Thank you!
hdk

There is a bug in your code: you are calling the incorrect overload of CKKSEncoder::encode for encoding a single integer. Your double is cast to 0 so the plaintext is identically zero. multiply_plain with an identically zero plaintext doesn't make sense and is not allowed, which is what the transparent ciphertext guard correctly catches.
I've made this mistake too. It would probably be a good idea to rename the CKKSEncoder::encode overload for a single integer to something else to avoid issues like this. The difference between the single floating-point and the single integer versions is that the single-integer version doesn't require a scale to be given (it uses scale 1.0).

Thanks Kim!! This is really helpful. All solved.

Hello! I was trying to solve the exact same problem, I checked if something had changed in the ckks.h since what you said about the "calling the incorrect overload" however I found that calling CKKSEncoder::encode was still in such an overload. I was wondering if there is a way to specify which type you're using or how exactly was this solved? Initially I thought it was missing a double scale variable...  but then I tried that, ckks_encoder.encode(p, scale, ptext); to try to call the
inline void encode(
double value, double scale, Plaintext &destination, MemoryPoolHandle pool = MemoryManager::GetPool())
{
encode(value, context_.first_parms_id(), scale, destination, std::move(pool));
}
Is there something I'm missing?

authors: MyrrhDev hdk0102 kimlaine


text:
Update pipeline

Add condition for notice.

Same changes merged via PR #144.

Update in pr #144


text:
Incorrect syntax highlight when a keyword is followed by a tagged string.

VSCode Version: 1.40.2
OS Version: Windows 7

Steps to Reproduce:

Type

return`tagged string`; // no space between return and backtick.

the keyword return is highlighted as part of the string instead of a keyword.

When a space is inserted after return, however, the syntax highlight would work as expected.

Does this issue occur when all extensions are disabled?: Yes

Confirmed with latest grammar version. Example valid code that is highlighted incorrectly:
const a = () => {
	return`tagged string`;
};

authors: infinnie mjbvz

repo: microsoft/TypeScript-TmLanguage


text:
Unreachable code defaults

Apparently, since 2.9.1, unreachable code is allowed by default, you have to explicitly set allowUnreachableCode to false in tsconfig.json to get the old behavior.
This doesn't match what's described in the docs.

Quick repro :
package.json
{
  "name": "tmp",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "typescript": "2.9.1"
  }
}

tsconfig.json (default from tsc --init)
{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true
  }
}

index.ts
export const a = (): boolean => {
    return true;
    return false;
};

yarn tsc outputs no warning as of 2.9.1

See #24320

The docs on --allowUnreachableCode just cost me half an hour; I hope that PR hasn't stalled, for the sake of others.

The documentation is still wrong. When the compiler is called in command line mode, unreachable code is not reported at the console unless allowUnreachableCode is explicitly set to false.
see #24261

A note for Visual Studio (vscode) users: it appears that when vscode uses tsc for code analysis, when allowUnreachableCode is unset in tsconfig.json, it follows the documented behavior and assumes the default is false. This can lead you to a bad time when your command-line compiler and Visual Studio disagree on whether unreachable code is allowed.
Picking a value and setting it in tsconfig.json appears to fix the issue.

authors: Mr-Wallet andy-ms chdh fixermark kamek-pf

repo: microsoft/TypeScript


text:
Infinite build regression in 3.2+

TypeScript Version:  3.2.1 - 3.3.0-dev.20190108
Search Terms:
infinite, build, memory
Code
this is something I need help to narrow down
Expected behavior:
project built successfully as it is done in TSC 3.1.6 and below
Actual behavior:
node.exe allocates memory in ~300Mb chunks and release about 280Mb of it repeatedly leading to OOM after some time
Issue occurs after error check stage, because if project has build errors, it stops after errors repored.
** tsconfig **
tsconfig:
{
    "extends": "../tsconfig",
    "include": [
        "../definitions/ts/*.d.ts"
    ],
    "files": [
        "../definitions/includes.ts",
        "../external/root.ts",
        "root.ts"
    ],
    "compilerOptions": {
        "types": [ "jquery", "kendo-ui", "jstimezonedetect" ]
    }
}

parent tsconfig:
{
    "compileOnSave": false,
    "compilerOptions": {
        "typeRoots": [ "../../../../node_modules/@types/" ],
        "noEmitOnError": true,
        "noUnusedLocals": true,
        "noUnusedParameters": true,
        "removeComments": true,
        "target": "es5",
        "strict": true,
        "noImplicitReturns": true,
        "noFallthroughCasesInSwitch": true,
        "forceConsistentCasingInFileNames": true,
        "noErrorTruncation": true,
        "allowJs": true,
        "lib": [
            "dom",
            "es5"
        ],
        "stripInternal": true,
        "declaration": false,
        "jsx": "react",
        "jsxFactory": "Templates.compile"
    }
}

Guys, I think I need some help narrowing down this issue/repro. I can attach to build using debugger, but because it looks like some iterative process and call stack doesn't give me any idea where to look as I'm not really familiar with tsc internals - I think I need some directions what I should check.
Random stacktraces:
    at updateLineCountAndPosFor (c:\Perforce\node_modules\typescript\lib\typescript.js:11048:42)
    at Object.write (c:\Perforce\node_modules\typescript\lib\typescript.js:11066:17)
    at writePunctuation (c:\Perforce\node_modules\typescript\lib\typescript.js:84291:20)
    at emitTypeLiteral (c:\Perforce\node_modules\typescript\lib\typescript.js:82616:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:82003:32)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)
    at emitFunctionType (c:\Perforce\node_modules\typescript\lib\typescript.js:82574:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:81995:32)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)"

    at writeTrailingSemicolon (c:\Perforce\node_modules\typescript\lib\typescript.js:84293:40)
    at emitPropertySignature (c:\Perforce\node_modules\typescript\lib\typescript.js:82476:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:81971:32)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)
    at emitNodeList (c:\Perforce\node_modules\typescript\lib\typescript.js:84233:21)
    at emitList (c:\Perforce\node_modules\typescript\lib\typescript.js:84108:13)
    at emitTypeLiteral (c:\Perforce\node_modules\typescript\lib\typescript.js:82615:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:82003:32)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)"

    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:81931:38)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)
    at emitNodeList (c:\Perforce\node_modules\typescript\lib\typescript.js:84233:21)
    at emitList (c:\Perforce\node_modules\typescript\lib\typescript.js:84108:13)
    at emitTypeLiteral (c:\Perforce\node_modules\typescript\lib\typescript.js:82615:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:82003:32)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)
    at emitFunctionType (c:\Perforce\node_modules\typescript\lib\typescript.js:82574:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:81995:32)"

We'd really need a repro to assist further

Retested it and it works fine again starting from v3.5.1.
just in case attached files to reproduce it
issue29326.zip

authors: MaceWindu RyanCavanaugh


text:
Infer class type from keyof class type

TypeScript Version: 3.8.2
Search Terms: infer, class, type, from, keyof, class, member, prop, deduce
View on TS Playground
Description:
// define a class
class MyClass {
  a?: string;
  b?: string;
}

// get the union type of the class keys
type MyFieldKey = keyof MyClass; // "a" | "b"

// create a utility type to get the class type from a given key type
type ClassType<FieldKey extends string | symbol> =
  FieldKey extends keyof infer ClassType ? ClassType : never;

// get the class type from the key type
type MyClassInferred = ClassType<MyFieldKey>; // the problem...

In this example, one might expect for MyClassInferred to have a signature of MyClass. Instead it has the following signature: { a: any } | { b: any }.
Is this by design?
Thanks!
Kind regards,
Harry

Stack Overflow might be a better place for this, since this does seem to be working as intended.
I'd say that K extends keyof infer T ? ... or the non-distributive equivalent [K] extends [keyof infer T] ? ...  is unlikely to be a useful construct since all the compiler can reasonably infer for T is something like Record<K, any>.  You've asked the compiler to infer a type which has a key a and/or b.  It dutifully responds {a: any} | {b: any} (or {a: any, b: any} if non-distributive), which is valid.  It does not scan through all other types mentioned in the code to see if there's another type which it can use in stead.  That might make sense in a nominal type system where you could hope to enumerate all types, but in a structural one where types can exist without explicit declarations, it's a non-starter.  Hope that makes sense; good luck!

@jcalz thank you! Before you close the issue, I hope it's okay if I run a single use case by you, as I believe this nominal-ish feature is one of importance to the language.
Let's say you're using a validation library, which exports a decorator factory Validate. This factory accepts a function, whose first argument is the class and whose second is a specified member of that class (the field being decorated). We'd want to create a type for the factory-passed function. For now, let's call this type––the argument of the Validate decorator factory––Validator.
import {Validate, Validator} from "some-wild-validator"

class User {
  name: string;
  @Validate(validator)
  age: number;
}

// within here, we need two generic arguments in order to get correct inference on `user` and `age`
const validator: Validator<User, "age"> = (user, age) => {
  // do something
}

If it were possible to use the infer type to work backwards from User["age"], we could make the following possible, while keeping the correct inference:
const validator: Validator<User["age"]> = (user, age) => {
  // do something
}

2 generic arguments -> 1 generic argument. Not a huge difference, but ice cool nonetheless.
I'd love to hear thoughts on this.

@harrysolovay Have you found any solution to infer the rest part of the interface?
I ran into this issue this week and still have not figuredout how to make it.

authors: harrysolovay huan jcalz


text:
"Object is possibly null" After Non-Null Assertion

TypeScript Version:  3.7.x-dev.201xxxxx

Search Terms:
typescript object is possibly null after non null assertion
typescript object is possibly null after exclamation mark check
Code
const obj: { a: number } | null = null;

if (obj!.a) {
    console.log(obj.a);
}

Expected behavior:
Successful compilation, since we notify the compiler with non-null assertion at line 3 that obj is not null, then it's not null at line 4 too.
Actual behavior:
Error "Object is possibly null" at line 4 (console.log(obj.a)).
Playground Link: https://www.typescriptlang.org/play?ts=3.9.0-dev.20200328#code/MYewdgzgLgBCBGArAXDA3jAhqsBXAtvAKYBOMAvjAD4x4A2dMAvLbgwNwBQnAlgGYwAFAkQBCAHSYAlOk4x5MUJBB0i4uiADmwpJKldycmEA
Related Issues:

I guess you meant to use the optional chaining here? https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#optional-chaining
const obj: { a: number } | null = Math.random() > .5? null : { a: 42 };

if (obj?.a) {
    console.log(obj.a);
}

https://www.typescriptlang.org/play?ts=3.9.0-dev.20200328#code/MYewdgzgLgBCBGArAXDA3jAhqsBXAtvAKYBOMAvjAD4x4A2dMAvDALKZQAWAdCZmABMQ+ABQBKGAD4Y3AKwB+WrgYxUGbDAAsAJgoBuAFAGAlgDMYIhInndMEtAZhOYoSCDpFudEAHNLSWzFDckcYIA

@nicojs No. I mean non-null assertion.
I know that works with optional chaining operator, but that's not the case. It should produce no errors even with non-null assertion, since we let the compiler know (at line 3) that obj, not matter what you (= the compiler) knows about it, is NOT null. And since we don't assign null to obj between line 3 and 4, if in line 3 it can't be null - it can't be at line 4 too.

I'm pretty sure the non-null assertion operator works as intended here. With non-null assertion you're effectively saying to TypeScript "I know it might be nullish, but I know better, please let me use it this one time". It doesn't interfere with control flow analysis.
Although this is not explicitly found in the handbook: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html#non-null-assertion-operator. Maybe adding this small example could help with that?

@nicojs What's the point? If obj is null, it'll crash. If not, why we emit an error in the next statement?

See #9640
In general we don't do "if it didn't crash" reasoning since it's very difficult to fit into an efficient control flow analysis, which is really what you're asking for since the same reasoning would apply to this example:
const obj: { a: number } | null = null;

if (obj!.a) {
}
console.log(obj.a);

authors: ChayimFriedman2 RyanCavanaugh nicojs


text:
Single line comments should generate selection ranges

Bug Report

🔎 Search Terms

selectionRange
Smart selection
expand selection

🕗 Version & Regression Information
Reproduces in 4.3.0-dev.20210210
Not a regression
💻 Code
For the code:
const a = 123 // a b c

Put the cursor in the comment and run expand selection
🙁 Actual behavior
A single selection range for the entire line is returned:
[Trace  - 09:12:08.176] <syntax> Sending request: selectionRange (53). Response expected: yes. Current queue length: 0
Arguments: {
    "file": "/Users/matb/projects/san/a.js",
    "locations": [
        {
            "line": 1,
            "offset": 19
        }
    ]
}
[Trace  - 09:12:08.177] <syntax> Response received: selectionRange (53). Request took 1 ms. Success: true
Result: [
    {
        "textSpan": {
            "start": {
                "line": 1,
                "offset": 1
            },
            "end": {
                "line": 1,
                "offset": 25
            }
        }
    }
]

🙂 Expected behavior
There should be a selection range for the single line comment.
Preferably, I think there should actually be two here:

One for the comment body: a b c
One for the entire comment: // a b c

Thanks @a-tarasyuk!

authors: DanielRosenwasser mjbvz


text:
es2020.intl.d.ts is inaccurate

lib Update Request

fractionalSecondDigits, dateStyle, timeStyle, dayPeriod are in ES2021 draft, not ES2020.
NumberFormatOptions should have the list of sanctioned unit to prevent RangeError.

Reference upstream issue: https://github.com/formatjs/formatjs/issues/2616

Configuration Check

Missing / Incorrect Definition
lib/es202.intl.d.ts
Sample Code
Documentation Link
https://402.ecma-international.org/7.0/

In with https://github.com/microsoft/TypeScript/pull/45647 👍🏻

authors: longlho orta


text:
Compilation dependencies with mixins

Bug Report
When using incremental compilation with typescript (3.x and 4.x), it seems that the compiler considers any change to a mixin class as requiring recompilation of all clients and subclasses of that class.
For non-mixin classes, it seems that the compiler does not force recompilation for clients and subclasses when a method body is changed or when a hard private (e.g. #x: number) member is changed (added/removed/type changed) (it is unclear how dependencies are calculated for soft private members).
The cause seems to be, somehow, in the type inferred for the mixin function result, but this type should not depend on method bodies and privates.
🔎 Search Terms

incremental compilation
mixins
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
I was unable to test this on prior versions because _______

⏯ Playground Link

Playground link with relevant code
💻 Code
In the code below, we have 4 files:
Mixin is a basic mixin
Class is a similar class,
Client is a client that uses both Mixin and Class
Subclass is a file with subclasses for Mixin and Class

//File: Mixin.ts

type Constructor<T = object> = new (...args: any[]) => T;

export const Mixin = <TBase extends Constructor>(Base: TBase) => {
  abstract class Mixin extends Base {
    private f(): number {...}
    protected g(): number {...}
    h(): number {...}
    #x: number;
    private y: number;
    protected z: number;
    w: number;
  }
  return Mixin;
};

type AnyFunction<A = any> = (...input: any[]) => A;
type Mixin<T extends AnyFunction> = InstanceType<ReturnType<T>>

export type TMixin = Mixin<typeof TMixin>;

//File Class:
export class Class {
  private f(): number {...}
  protected g(): number {...}
  h(): number {...}
  #x: number;
  private y: number;
  protected z: number;
  w: number;
}

//File Subclass:
class MixinSubclass extends Mixin(Object) {}
class ClassSubclass extends Class {}

//File Client:
class Client {
  x: TMixin;
  y: Class;
}

//(we did not include import statements)
// We can quickly address your report if:
//  - The code sample is short. Nearly all TypeScript bugs can be demonstrated in 20-30 lines of code!
//  - It doesn't use external libraries. These are often issues with the type definitions rather than TypeScript bugs.
//  - The incorrectness of the behavior is readily apparent from reading the sample.
// Reports are slower to investigate if:
//  - We have to pare too much extraneous code.
//  - We have to clone a large repo and validate that the problem isn't elsewhere.
//  - The sample is confusing or doesn't clearly demonstrate what's wrong.

🙁 Actual behavior

We have observed that any change to Mixin - that is, to Mixin.#x|y|z|w and even the bodies of f(),g(),h() causes recompilation of both Client.ts and Subclass.ts,
If we modify Class.#x|y|f() we do not observe recompilation of Client.ts or Subclass.ts, and if we modify Class.z|g() we do not observe recompilation of Client.ts, as expected.
In addition modifying method bodies in Class do not cause any recompilation, and as well adding more imports or non-exported declarations
🙂 Expected behavior

For Mixin, we would expect that only changing h() and w will recompile Client.ts and in addition changing g() and z will recompile Subclass.ts, we also expect that modifying any of the method bodies including h() and g(), will not recompile any other file, unless the body is used to infer the return type of the method (and then only if the return type actually changed).

any change to a mixin class as requiring recompilation of all clients and subclasses of that class.

Which compilation method are you referring to here? Watch mode? Incremental? Build mode? Something else?

any change to a mixin class as requiring recompilation of all clients and subclasses of that class.

Which compilation method are you referring to here? Watch mode? Incremental? Build mode? Something else?

Incremental.
I did not test with watch mode but I would guess it should be the same?
I could not find much documentation on how compilation dependencies are calculated for incremental compilation.

authors: RyanCavanaugh UJEsri


text:
noThirdPartyAny to flag anys that come from third-party type declarations

Suggestion
🔍 Search Terms

noImplicitAny @types

Related:

https://github.com/microsoft/TypeScript/issues/33886
https://github.com/microsoft/TypeScript/issues/27265
https://github.com/microsoft/TypeScript/issues/26188

✅ Viability Checklist

My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code (it would have to an opt-in via a new flag)
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
I'd like to add a new flag, perhaps noThirdPartyAny, that makes it an error for a symbol to have an any type if that any comes from third-party code, e.g. from @types or from lib/dom.d.ts. (Just like with noImplicitAny, it would be fine if you wanted to explicitly give that symbol an any.)
📃 Motivating Example

TypeScript with noImplicitAny requires you to provide type annotations on all symbols that would otherwise implicitly have an any type. You'd think that this would only leave you with explicit anys, i.e. a symbol can only have an any type if you write the word any somewhere.
But that's not quite true because type declarations files (@types) can include any types as well.
Maybe the most common example is JSON.parse (also Response.prototype.json()):
const data = JSON.parse('{"a": 12}');
const b = data.b.toString();  // 💥

I'm using --strict and I never wrote any, but the type of b is still any and it leads to a runtime error that TS misses.
Here's a more intricate React example that tripped me up this week:
import React from 'react';

function MyComponent() {
  const [value, setValue] = React.useState('');
  return (<input onChange={e => setValue(e.currentTarget.value)} value={value} />);
}

This works correctly. The e parameter in the callback has a type of React.ChangeEvent<HTMLInputElement>, which is exactly right.
Now I decide to memoize the handler using React.useCallback, copy-pasting my callback:
import React from 'react';

function MyComponent() {
  const [value, setValue] = React.useState('');
  const handleChange = React.useCallback(e => setValue(e.currentTarget.value), []);
  return (<input onChange={handleChange} value={value} />);
}

Again, this works (at runtime) and it passes the type checker. But it's actually a looming disaster because e now has an any type! This comes from the React typings:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/07e9b3d9d301b7d17390c16816c02cdf92706ecb/types/react/index.d.ts#L1099-L1107
This use of any is a known issue (https://github.com/DefinitelyTyped/DefinitelyTyped/issues/52873) that the maintainers prefer not to fix until the next major version of React comes out. That's fine, but it makes useCallback very any-prone.
I've found that anys that come from @types and the built-in libraries are quite common and always surprising. They let anys creep into your code even when you think you're being strict. I'd like some way to have TypeScript help me fight back against these implicit anys.
💻 Use Cases

See above. noImplicitAny solves this for anys that are truly implicit. I'm proposing a new flag that would extend this to any symbols that do appear explicitly in type declarations, just not ones that I wrote.
You can use declaration merging to eliminate these on a case-by-case basis (see blog post) but this feels like playing whack-a-mole. The new --useUnknownInCatchVariables flag is another tool in this game of any whack-a-mole.
The best way to spot these any leaks is with ts-coverage (https://github.com/plantain-00/type-coverage), which reports every symbol in your code that has an any type, wherever it came from. The downside is that this exists outside the TypeScript toolchain, so I tend to only run it every once in a while, whereas type errors always get fixed immediately.

What would "third-party type declarations" mean? Every import that's not relative and every declaration file? I don't think TypeScript has a concept of "third-party".

I was wondering about that. Maybe something to do with typeRoots? Or by default, node_modules/@types?

The downside is that this exists outside the TypeScript toolchain, so I tend to only run it every once in a while, whereas type errors always get fixed immediately.

This sounds imminently fixable with an editor extension.

Yes, I think one of my takeaways here is that I should spend a bit more time trying to understand why the type-coverage VS Code extension has never worked for me.


text:
Array optional chain prototype is undefined

Bug Report

🔎 Search Terms
Array.prototype.length, undefined, optional chaining
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about refinements

⏯ Playground Link

Playground link with relevant code
💻 Code

interface MenuItem {
    name: string;
    children?: MenuItem[];
}

const item: MenuItem = { name: 'user' };

const { children } = item;

if (children?.length > 0) {
    console.log(children);
}

🙁 Actual behavior
Object is possibly 'undefined'
🙂 Expected behavior
No error

You get this error because you're trying to compare a potential undefined value with 0. This is completely unrelated to the optional chaining.
const num = Math.random() > 0.5 ? undefined : 1
if (num > 0) {
    console.log(children);
}

@MartinJohns I know, but I want to allow them to compare without reporting error.

You can remove the undefined type from the equation in several ways:

Avoid it, by adding a check: children && children.length > 0
Add a fallback value: children?.length ?? 0 > 0
Add a type assertion: children?.length as number > 0
Disable strictNullChecks.

Alternatively you could create a feature request to ask the TypeScript team to specifically support the pattern you use.

Feels like a duplicate of #45543 to me

authors: MartinJohns jcalz kaysonwu


text:
Provide way to link to other files from JSDoc comments

Suggestion
🔍 Search Terms

quickInfo
markdown
link
relative path
jsdoc

⭐ Suggestion
On VS Code, we have a long standing feature request to support relative file paths inside JSDoc comments:  https://github.com/microsoft/vscode/issues/86564
For example, if if I have a file folder/foo.ts:
/**
 * [link](./other.js)
 */
export declare function foo(x: string, y: {}): void

Then anywhere the documentation for foo is shown, we should render link as a clickable link to folder/other.ts.
On the VS Code side today, we can support rendering link but do not know what relative paths inside the documentation should be relative to
Proposal
To fix this, I propose that requests that return documentation also include a path that tells us which file the documentation comes from
Here's an example using quickInfo:
[Trace  - 17:11:37.514] <semantic> Response received: quickinfo (292). Request took 2 ms. Success: true
Result: {
    "kind": "function",
    "kindModifiers": "export,declare",
    "start": { "line": 4, "offset": 25    },
    "end": { "line": 4, "offset": 28 },
    "displayString": "function foo(x: string, y: {}): void",
    "documentation": [
        {
            "text": "[link](./files.js)",
            "kind": "text",

             // new field
             "file": "/absolute/path/to/folder/foo.ts"
        }
    ],
    "tags": []
}

This would likely be a new field on SymbolDisplayPart

FWIW there's not necessarily one file. In some cases we collate the documentation from multiple declarations.

We have a component that's using webhooks so it needs a public url to work and we wrote up docs on how to setup ngrok to use it and then hit the question of where to store it - I couldn't get anything to work well so adding my thoughts here for the discussion:

ultimately any solution probably should work with @see, @link, and [markdown-style](links) but it might be tricky to stay backward compatible

personally I'd love if [link](./path) was relative to the current file location like it is today but there was something else like [link](/path) relative to the repo root since I'm likely to want to reference things there and things that aren't in the usual import paths

/**
  Uses the [foo-service's bar endpoint](https://github.com/org/foo-service/blob/trunk/docs/bar.md) to do things.

  Also look at our relative [doc](./doc.md) and our top-level [README](/README.md)

  @see {@link /README.md#using-foo-service how to use the foo service}
  @see /docs/using-services.md#foo
*/

lastly, the only way for my foo function in foo.ts to reference bar in bar.ts is to import bar from ./bar but our code tooling will correctly say that bar isn't used and remove that import on save - so I think @see and @link would further benefit with a syntax for this that can also reference exported members so that clicking scrolls to the right line that references it - I saw things like @see BarClass#barProperty already works for things that are imported, so maybe something like @see ./bar.ts#BarClass#barProperty for things that aren't imported - double hash tag is a little odd but it's the most semantic thing I can think of cause it literally is an anchor to a spot in a file and it stays similar to the other syntax for class members

// -- foo.ts ---------------------
/**
  This function does foo stuff.
  See [bar](./bar.ts#bar) for an example of how to use it.

  @see ./bar.ts#BarClass#barProperty
*/
function foo() {}

// -- bar.ts ---------------------
import foo from './foo'

function bar() {
  foo()
}

class BarClass {
  barProperty: string
}

(Also for consideration: it'd ultimately be important for vscode and similar editors to be able to update the file paths here when files are renamed and the function, class, and property names when they're renamed to avoid breaking links, I'm assuming TS helps to feed data for those features to work.)

It shouldn't just support line numbers, it should also support references to symbols (and other jsdoc created symbols).
Typedoc provides something similar to this.
We have design system components that use keys of our design system tokens as an abstraction.
We'd like to be annotating those props with a link to the actual design tokens so it can help developers interpret figma designs.
If we were only able to use line numbers, then they'd become a problem to update over time.

It shouldn't just support line numbers, it should also support references to symbols (and other jsdoc created symbols).

Agreed. That would be fantastic. Line numbers would, over time, always end up being incorrect, and cannot be verified by some sort of "link checker" either

Rather than linking to a line number, could such a link... link to another specific symbol? @link theImportantDocumentation-> @target theImportantDocumentation ?

+1 Please add native support.

Loving +1 that a user-friendly way of simply using @link to refer to a relative file would be great. Personally would love inline for the format @see {@link ./myFile.js}

+1 for @nickyonge proposal.

I think, here are the three main wishes in this thread:

relative links (ref)
direct links to dependencies (ref)
support for line + column numbers (ref)

+1 to {@link 'relative/path/file.ext:row?:col?'
Don't know much about the JSDoc ecosystem, but would be nice if it could resolve paths specified in jsconfig.js and tsconfig.ts. I guess this behaviour could be a flag in the IDE settings for better SOC and ultimately JSDoc configuration itself needing to support path mappings for this particular functionality.
On an unrelated note... I soLvEd iT gUyS 🤪: {@link file://./sibling.ext} -- I mean it does actually work for me on macOS@13.4 and vscode@1.82.2, but only for paths starting with ./ coudn't make ../ work lol. Absolute paths work for anything though if you wanna go there. Though I had use triple slash after file:: file:///baby/shark/doodoo.ts

@js1m I was able to make ../ work by doing this {@link file://./../../sibling.ext}

thank you @sagargurtu, I think it is not a TypeScript thing but a VS Code thing, it allows you to reference file in a comment.
You can do this:
/**
 * Some bla bla from file://./../../lib/Task/index.ts#ITask
 */
const updateReport = (id: string, selected: ITask[]) => {}

And it actually works, you can navigate to that file.

@huksley Are you sure that you don't have any extentions which provides this? Because for me it is not working. Neiter locally nor wsl. VS Code is always showing an error message "Unable to open.." and that it cannot create the file

@terenc3 Try
/**
 *
 */

comment style. I don't think I have special extensions to handle this. I use Mac OS if that makes a difference.

Tried on Mac OS and it works, on Windows 11 it doesn't 😞

It would be great if a solution to this would support clickable links in both the document editor and the rendered hover.
I'm on Mac OS v14.3.1 VSCode 1.90.1 and found - with all extensions disabled, editor.links not explicitly set, and despite https://github.com/microsoft/vscode/issues/86564 still open (?):
/**
 * [link](./other.ts)
 * works in rendered hover, but not in document
 */

Screen Capture
https://github.com/microsoft/TypeScript/assets/14281373/812ad386-4263-44d8-aab0-dac107860633

and (as has been mentioned, since 2020 - although not on windows?):
/**
 * file://./other.ts
 * works in document, but not in rendered hover
 */

I tried (unsuccessfully) to combine them to  work in both.
 * // explicit relative paths
 * [markdown explicit](./other.ts) - rendered:works, document:not working
 * [markdown with explicit file](file://./other.ts) - rendered:wrong location, document:works
 * {@link file://./other.ts|link explicit} - rendered:not working, document:wrong location
 * {@link file://./other.ts} - rendered:not working, document:works
 * {@link [link markdown explicit](file://./other.ts)} - rendered:wrong location, document:works
 * file://./other.ts - rendered:not working, document:works
 *
 * // implicit relative paths
 * [markdown implicit](other.ts) - rendered:works, document:not working
 * [markdown with implicit file](file://other.ts)  - rendered:wrong location, document:wrong location
 * {@link file://other.ts|link implicit} - rendered:not working, document:wrong location
 * {@link file://other.ts} - rendered:not working, document:wrong location
 * {@link [link markdown implicit](file://other.ts)} - rendered:wrong location, document:wrong location
 * file://other.ts - rendered:not working, document:wrong location
 */

Another way to use @link is to point it to a variable. Here I wanted to link to my Server class connect method but the current file did not import Server directly. So, I did this:
/** Schema for {@link projectService.repo.server.connect} options */

The way we've been doing it at work is with type-only imports. An excerpt from our standards document, from the part on how we mark deprecations:
// file: newFunction.ts
export function newFunction() {}

//file: deprecatedFunction.ts
import type { newFunction } from "./newFunction"

/** @deprecated use {@link newFunction} */
function deprecatedFunction() {}

You can already link to other files. You can do
/** @see file:///C:/jsproject/jsfile.js */
function foo() { }

And VSCode will find it. The problem is more that we don't have a way to specify relative paths with file:// so everything needs to be absolute.
You can also link to types declared in other files (if Typescript picks it up):
/** @see {FooObject} */
function foo() { }

You can even link to functions:
function foo() { }

/** @see {foo} */
function bar() { }

You cannot do this across files since import will not work.  but @template does work, so you can hack the link into it with a useless template.
/** @template {import('./barfile.js').barFn} T99 */
function foo() { }

The only caveat is that the type must be exported.

This works in VSCode:
/**
 * {@link file://./foo.ts}
 */

Special note for when you try to go a level above, you still need to start with ./:
/**
 * {@link file://./../bar.ts}
 */

Thanks @romulof, for the info about parent directory traversal.
I additionally would like to add that the hyperlink rendering doesn't render as expected, but the functionality works when used with a relative path
/**
 * @see {@link file://./../../../@types/foo.d.ts | Foo}
 * @see {@link http://github.com | GitHub}
 */

Why not both?
Simple but repetitive... I appreciate how irritatingly un-DRY it is though :grimacing:.
I'm just happy I can click through to the file via both comment or tooltip :tada:.
Code Snippet
/**
 * See the {@link http://eslint.org/docs/user-guide/configuring ESLint docs} for info on how to configure eslint files.
 * Check out {@link https://github.com/Shinigami92/eslint-define-config these docs} for help with how to use `defineConfig` and `defineFlatConfig`.
 *
 * ### Other lint configs:
 * - [Unit Tests](./tests/unit/.eslintrc.cjs) {@link ./tests/unit/.eslintrc.cjs}
 * - [E2E Tests](./tests/e2e/.eslintrc.cjs) {@link ./tests/e2e/.eslintrc.cjs}
 */

How comment renders in VSCode

How tooltip renders in VSCode

same need + 1

+1 requesting

authors: DDD-fx Domiii EmilyRosina GlenPierce-Workday RyanCavanaugh airtonix clshortfuse huksley joshuambg js1m lake2 legowerewolf lflorent madhugod michaeldrotar mjbvz nickyonge romulof sagargurtu seahindeniz sebastian-fredriksson-bernholtz terenc3 waynebloss