Typescript: Enable Go to Implementation in Typescript Editors

So you want this functionality to jump to the corresponding .js if available, provided that the definition is ambient, correct?

@RyanCavanaugh @mousetraps @bowdenk7

So you want this functionality to jump to the corresponding .js if available, provided that the definition is ambient, correct?
Yes this is a scenario that would be very useful for productivity. This alone would be very valuable. I believe the atom-typescript author believes more hooks in the Typescript compiler would make it easier for him to implement this. I'm unclear on whether this is information on js implementation line numbers is information the typescript compiler would typically know internally.

In addition, another scenario would be enabling a jump to the original typescript .ts file definition in the library being used by the application. I would imagine this information is available pre-compile to d.ts and .js files. We now have entire sets of libraries being written in .ts files as source outputting ES5 syntax js. It would be nice to achieve the ability to jump to the original typescript implementation definition in the .ts files.

I'm aware this is asking even more to jump to the .ts file implementation in the required library as it might need source map usage or distribution of source/link to original ts source. It would seem to me that the typescript compiler that generates the initial library of functions and classes would know the lines where the implementation is at and could preserve the line numbers when the library is distributed somehow so that the typscript compiler of the application using the class could know what line to jump to in the library.

Is this information on line number of implementing function/class available in source maps? Are there other sources of this information?

Given that we are going to be using the --allowJS flag, the language service should be able to work with the JS files.

I don't know how .d.ts files and .js files currently work together in that respect. @sheetalkamat probably (definitely) knows more about this than I do.

Reopening, because going to js files isn't supported quite yet

Any updates on this one? The current state of typescript is that you cannot jump to the implementation of code in many prominent libraries.

This issue has been moved/closed/duped/deduped multiple times and fixing this bug could be a huge productivity boost.

https://github.com/ubershmekel/vscode-ts-goto-source has a project that reproduces the issue. As explained in https://github.com/Microsoft/vscode/issues/26325 and referenced in https://github.com/Microsoft/vscode/issues/10806 and https://github.com/Microsoft/vscode/issues/18321

Note I had to use "typescript.disableAutomaticTypeAcquisition": true from one point to use the javascript "go to definition" because it seems the .d.ts files take over if found.

@DanielRosenwasser Any updates on this? - Single most wanted feature for me.

This is particularily annoying if working in a monorepo written entirely in Typescript. I have multiple times when adding a field to a type or similar smaller changes used "go to definition", added it and then later found it missing again realizing that I added it to the .d.ts file and not the actual .ts file

@DanielRosenwasser Is this progressing? I would really love this feature

same issue. Want to "Go to implementation" to the source code, not xx.d.ts

Yep, multiple times a day I by mistake edit the declaration file after using cmd+click and end up confused when the code doesn't run correctly. Especially since src and dec look very similar. Would be awesome if there was some way to choose if I want to go to source of declaration, or even better if VSCode would figure this out as going to source is always more preferable IMHO (if it is available).

going to source is always more preferable IMHO (if it is available)

When the source is in TS. If the source is in JS though there's a good reason to go to the .d.ts

When the source is in TS. If the source is in JS though there's a good reason to go to the .d.ts

Why? I can just hover to see the type definition. Anyway, there should be a separate command for type definition vs implementation.

Is there any reason why this is still pending? A workaround, alternative or something? Thanks in advance

Since the Typescript parser often generates the d.ts files from the .ts implementation files. Could that association between the d.ts and .ts files be preserved (perhaps output with a typescript compiler option) so that Typescript editors could take developers to a list of the implementing classes or functions?

I have a branch of #21930 that enables producing precisely these declaration file sourcemaps (and will have that out for review either on request or once #21930 is merged), and am working on adding support into our LS for following these maps. We want to ship it in 2.8.

So yeah, we've been working on it. It just needed a lot of internal changes. 😄

Expect updates on this issue to relieve the pain on finding implementations through manually expand folders under node_modules and locate the entry module file.

Is there any workaround for this?
As we have a big module for our db queries written in ts it would be really nice to see the real source code with one command instead of searching through the node_modules.

@derN3rd There is vscode-search-node-modules extension to browse node_modules in the command panel (and I also have a fork which always opens README vscode-open-node-modules)

I understand it's far from the perfect ux to click on require/import and open source a file, but definitely better than scrolling node_modules

@derN3rd we will be shipping a --declaratrionMap flag in 2.9 (which may be released during next month), and we've already enabled going to definitions in the original source TS over an associated .d.ts using them (which, if you're shipping declaration files in your node modules folder may get a lot of what you want). We're also looking into jumping to/from the associated JS as well, provided normal sourcemaps are also on.

@weswigham thanks for the fast reply! Sounds good
Could you post an update here if the feature is ready or ready to be tested?

--declarationMap (and associated LS redirection) has been in our nightlies since just after the 2.8 release. The only bit we've not done yet is the JS file hopping, as that may require some extra editor coordination.

Any news for that on 3.0-rc?

Same issue with .css and .json files. Go to Definition taking me to .d.ts file.

import React from 'react'
import Route from 'react-router-dom/Route'
import Switch from 'react-router-dom/Switch'
import Loadable from 'react-loadable'
import  './App.css'
import './tailwind.css'

Go to Definition on ./App.css takes me to

declare module '*.css' {
    const content: any;
    export default content;
}

declare module '*.svg' {
    const content: any;
    export default content;
}

declare module '*.json' {
    const content: any;
    export default content;
}

VS Code now ships with TypeScript 3.0.3. Any news on this issue?

Works for me (declaration maps generated with TS 2.9.2, running VSCode 1.27.0). Navigating from an API consumer (implemented in JS) _Go to Definition_ takes me to the implementation in the .ts file.

@robsman _Go to Definition_ should take you to the compiled js code, while _Go to Type Definition_ should take you to the .d.ts file.

How do you use/include your compiled module, to open the source files?

That issue still exists for me in VSCode 1.27.0, as both functions take me to the .d.ts file

EDIT: I think I misunderstood your comment. Does it take you to the real code? If so, are you using a monorepo or is your compiled code shipped in a own npm module? Do you ship the source files with your compiled code?

@derN3rd re-tested, both _Go to Definition_ and _Go to Type Definition_ as well as _Peek Definition_ take me to the real code in the _.ts_ file.

The API declaration and implementation both sit in a separate module that the calling package refers to as a _git+ssh..._ dependency.

@robsman I think Go to Definition should refer me to source of "this" class or function in source js file (if it's javascript) inside node_modules not .d.ts. Like it works in Sublime Text 3 I mean. Anyway I don't understand for what VSCode this feature in the current state

Hope can prioritize this issue, it is really a big pain, from so many comments and related issues.

Please add me to the long list of folk trying to use command-click to navigate through the code. I have no TS in my project and the npm package I am navigating to does not use TS, yet command-click on require('co-body') takes me to an internally generated TS definition. I am long time IntelliJ user and still, because of this, I fall back to IntelliJ.

it's a long request

I like VS Code a lot and I just started a new Node project and decided to use TypeScript for the first time. So far so mostly good, but this issue has been a pain point. Working in open-source, the ability to click through to real source code in dependencies is vital to work-flow. I am working in TypeScript source files and using JS NPM modules with associated @types/xxx modules that have no associated documentation. IntelliSense with TypeScript is great, but doesn't always provide enough information. At the very least, being able to click straight through to the module source from the import statement would be nice. I believe on some libraries that works, and on others, e.g. Passport, I can't get past the adjunct TypeScript stubs in the @types module.

This should be labeled _Bug_, not _Suggestion_.

The lack of code navigation really ruins the VSCode experience for JavaScript developers.

sorry to spam the thread but @promaty I use the search-node-modules extension 😬 for now

WebStorm has the same behaviour: StackOverflow, BugTracker

• VSCode has "Go to Definition" and "Go to Type Definition" actions

• WebStorm has "Go To Declaration" and "Go To Type Declaration" actions

But when using TypeScript, both IDEs do the same thing: always go to the type definition!

"Go to Definition" and "Go to Type Definition", when used on node_modules/ libraries, both take me to .d.ts files. I'm on the latest VS Code as of writing (1.34.0).

For example: npm package @angular/[email protected], when I import TestBed from @angular/core/testing and try to see the definition of TestBed.createComponent, I get two different things:

• "Go to Definition" -> node_modules/@angular/core/testing/src/test_bed_common.d.ts line 117
• "Go to Type Definition" -> node_modules/@angular/core/testing/src/component_fixture.d.ts line 14

This basically means that the Angular source code is hidden from me in VS Code 😞 I'm not sure if that's a symptom of how the Angular library is written, or how TypeScript/VS Code finds source implementations.

All I know is I can only reliably use "Go to Definition" and "Go to Type Definition" on my own code, in which case I get taken directly to the source; I'm never shown a .d.ts file for my own code.

We have to manually search source codes for now :/

Aw, I just figure out that somehow Intellij IDEA have this function work really well, even I'm on the same project, using Typescript 3.0.1

I thought the priority of this issue should be bumped up.

We have to command + , to open the workspace settings -> uncheck Use Ignore Files -> delete Search: Exclude: **/node_modules, and manually search source codes.

EVERY DAY!

So that's why flow is still useful.

Could someone from typescript team suggest where in code this can be potentially fixed?

A funny thing is that if some package doesn't have types available "Go To Type Definition" actually works better for it. It means that not using typings is better if you like "Go To" features 😄

Here's screencast that shows that I'm able to go to definition of device packages that doesn't have typings, but compression leads me to some random typings file:

https://giphy.com/gifs/j3VCp0LVKr5LsMUh11

@RyanCavanaugh I must agree with other people, this should be labeled as bug, not suggestion..

in my case, if I have something like this defined in my own code

const Foo: <T> = () => {
...
}

if the T comes from a npm module, when I try to go to definition, it will show me 2 definitions. My own code and the typing definition. If I go to type definition it goes straight to the definition file.
In the first case, it should go straight to the definition.
To work around this, I changed the editor --> goto location: multiple to goto instead of peek

I need this feature. How can I help with its implementation?

+1 for this please!

since 2015 and no solutions :(

The OP was asking if we could go to .ts files when we find .d.ts files - if you ship the .ts files with the .d.ts files and the declaration maps generated by --declarationMaps, that is our current behavior (so that's pretty done). The _second_ request in this thread, which is what we now track here, is an option to go to the output .js file (which could be useful if, for example, the .ts sources aren't shipped). Implementation-wise, that's just a matter of combining the declaration source maps and javascript source maps we already emit, however what we haven't decided on is how such a feature should be surfaced. Go to implementation in ts code already has a useful meaning for most code (which is go to definition, but prefer implementation/value declarations)... do we amend that in some way (say, if we resolve to a declaration file, try to resolve to a js file instead), or do we add a new endpoint? If the later, we need to talk about how we want to surface it with the vscode team.

@DanielRosenwasser honestly, what we really need here is just a more fleshed out description of exactly how we wanna expose a thing like this - the tools to do it are now in place.

Coders from vscode team can propose ideas on how this should be implemented, eg Go to js implementation or something like that, a first good step would be to create a ticket on vscode issue tracker and cross-reference this tickets so that communication can begin.

My understanding is that there are several related problems here. (1) is the big one, but we should keep the others in mind too:
1) There's no easy way to navigate to the JS or TS implementation of a TS type if that type is declared in a DefinitelyTyped package. (or other cases where .d.ts isn't colocated with the implementation)
2) Go To Type Definition doesn't work when the selection is itself a type. You'll get a "no type definition found" error.
3) Go To Definition on a non-type identifier behaves inconsistently. Sometimes it will navigate to the implementation, sometimes it won't. In theory this is the same as (1), but it's also possible to solve (1) while leaving this inconsistency in place.

I think it would be simpler for users to solve all three problems _without_ adding a third "Go To" menu option. Instead, my suggestion would be to retain only two menu items but make them behave more consistently:

• Go To Definition should always navigate to the implementation, regardless of whether it's local code, a node_modules package with integrated .d.ts files, or a DefinitelyTyped definition that's separate from the JS package.
• Go To Type Definition should always navigate to the TS declaration, regardless of whether the selection is a type or a non-type identifier.

Are there other common TS use-cases that require a third choice?

BTW, I guess we could rename "Go To Definition" to "Go To Implementation" if we wanted to make the distinction clearer, but IMHO this seems like an optional change. Consistency (regardless of the name) is the high-order bit.

There's no easy way to navigate to the JS or TS implementation of a TS type if that type is declared in a DefinitelyTyped package. (or other cases where .d.ts isn't colocated with the implementation)

_Technically_ if you wanted to hand spin some sourcemaps to go with a DT package, it could kinda work out already. But there's definitely no automated solution here. Any solution we do have is based on improving scenarios involving TS compiler output, at those are the only times when we can otuput the additional metadata required to make the correct associations between files. Some packages support this today, I believe - I was using the azure js sdk the other day and debugging some stuff, and was pleasantly surprised when I went to some definitions and discovered they were in the original source. So yeah, it works with TS sources that have up-to-date --declarationMaps output bundled with them.

Go To Type Definition doesn't work when the selection is itself a type. You'll get a "no type definition found" error.

I think y'all should open a new issue on that one. That's just a failure of exepections/bug, imo. Minimally, the error could be made better - something like "selection is only a type and so has no type definition associated with its value".

Go To Definition on a non-type identifier behaves inconsistently. Sometimes it will navigate to the implementation, sometimes it won't. In theory this is the same as (1), but it's also possible to solve (1) while leaving this inconsistency in place.

It goes to the _first_ definition, where first is pretty arbitrary, and based on things like the order files were loaded in. The peek window is admittedly more useful, since it shows all definition sites. "Implementations" don't come into play.

As a user, I will be satisfied, if it worked like this:

Ctrl+Click on a symbol (I mostly use only this to navigate the code) brings currently to either an implementation (if it is within the package being edited in VS Code) or to the declaration (if it is a package from the dependencies). The first does not require consideration. The second, when it goes to the declaration, I would like to Ctrl+Click on the declaration and it navigates me to the implementation, if it can locate, download and open it for me. Otherwise, it shows a message what problem prevented the sources to be found / opened. If it worked like this, it would be awesome.

I believe there are the following scenarios with locating the original source code:

1. A package is written in typescript and original source code in external repository and either
   a) distribution includes d.ts and js files OR
   b) distribution includes d.ts, js and ts files
2. A package is written in typescript and original source code in the current repository (mono repo case) and
   a) distribution includes d.ts and js files
3. A package is written in javascript and original source code in external repository and either
   a) distribution includes it's own d.ts and js files OR
   a) distribution includes only js files and external @types definitions are used
4. A package is written in javascript and original source code in the current repository (mono repo case) and
   a) distribution includes it's own d.ts and js files

1b) - is rarely used, and I do not like this approach as resources like bundlephobia and npm trends will report huge package sizes, which are not huge in runtime really, but people judge the size based on these resources. So, relying on the maintainers to include ts files with the distribution is not a good idea, but certainly if ts files are included, the case is solved.

1a) - (most?) frequent case. The package should some how declare (via package.json or source maps?) where the original sources were located when compiled (like microsoft pdb symbol files declare) OR where can be downloaded from, for example git+revision+path. VS code would navigate to the local file or git fetch it to the local cache and open it on navigation from declaration to the implementation

2a) - if it is possible to detect the case of mono repo automatically (using some heuristics), the original Ctrl+Click navigation could open the implementation directly. If it is impossible, fallback to 1a) is good enough

I care less about 3, but it would be nice if 3a) could open JS implementation on the second Ctrl+Click navigation. In case of 3b) the @types package should declare what JS packages it annotates, so VS code could have this information to navigate to the JS implementation in the external package.

I care even less about 4, but it could have the same behaviour as 2a) - fallback for 4a) is 3a)

Hope it helps.

1a) - (most?) frequent case.

Yeah, that's what I'm saying we have all the tools in place to support now. We can combine .js.map and .d.ts.map files to produce a mapping from .d.ts to .js (without the intermediate .ts). But, hm. Really, you'd prefer to go to the declaration file, and then interact again to go to the associated js? You'd not want to jump straight to the js?

"Really, you'd prefer to go to the declaration file, and then interact again to go to the associated js? You'd not want to jump straight to the js?"

In case of 1a), double jump or single jump are both fine for me. Although single jump can be considered as "more efficient", double jump has got the benefit of "reminding" the user that the second jump is a jump to the black box from the "library consumption" point of view (i.e. reminder that the source file being navigated to is not part of the current project). Maybe this behaviour could be made configurable.

In case of 3a), 3b) or 4, I certainly want double jump. I first want to see the declarations and only after this (in very rare cases, like debugging) the implementation. Jumping straight to JS skipping the TS declaration removes all the benefits of the declarations. So, I definitely want to see the TS declaration first.

(combining replies to @weswigham and @avkonst from multiple posts)

It goes to the first definition, where first is pretty arbitrary, and based on things like the order files were loaded in.

In the most common case where you want to go to the implementation for a particular imported symbol, why would there be multiple definitions? Is this a common situation?

produce a mapping from .d.ts to .js (without the intermediate .ts).

Not sure I understand "without the intermediate TS". Do you mean that even if the original .ts source is available, VSCode would navigate to the transpiled .js? That seems like a bad idea. If the original source is available, then VSCode should navigate there-- just like it would when the debugger steps into transpiled code that has a sourcemap. That said, if the package author was evil or lazy and didn't include the original TS source in their npm distro, then it seems reasonable for VSCode to fall back to the transpiled JS and perhaps show a warning message explaining why the user is seeing such weird, unreadable code and to encourage users to nag the package author to include the original source in their package.

Really, you'd prefer to go to the declaration file, and then interact again to go to the associated js? You'd not want to jump straight to the js?

I don't think a two-step would add value. I think it's much better to have distinct, consistent UX: use "Go To Type Definition" to navigate to the type definition, and use Go To Definition (or Go To Implementation-- whatever we choose to call it) to go to the original source code or, per above, to the transpiled JS if original source isn't available.

IMHO, it's much more confusing to have different behavior depending on whether the selected symbol is defined in your own code vs. in node_modules. It shouldn't matter. If I want to see the type, VSCode should take me to the type. If I want to see the implementation code, VSCode should take me there. This is especially true because, in large organizations, what's "my code" and what's "library code" isn't always a bright line. If someone else refactored code into a shared internal package, I shouldn't have to change how I navigate to that code.

I first want to see the declarations and only after this (in very rare cases, like debugging) the implementation.

Seems like it's clearer to require the developer to explicitly choose (by picking one menu item or another) whether they want to see a type declaration or to view the implementation code. Having navigation be inconsistent depending on where the code comes from seems unnecessarily confusing.

> Go To Type Definition doesn't work when the selection is itself a type.
I think y'all should open a new issue on that one. That's just a failure of exepections/bug, imo.

Yep, this could definitely be fixed first. I included it here because if my preferred solution ("Go to Definition always navigates to the implementation") is adopted, then users will get in the habit of using Go To Type Definition whenever they want to see the .d.ts, so it'd be weird if doing this on a type didn't act consistently to how it acts for a non-type identifier.

"It goes to the first definition, where first is pretty arbitrary, and based on things like the order files were loaded in."

I have not mentioned in my replies that it should navigate to the first definition. I said on Ctrl+Click on a symbol it should go first of all to the definition (as it works now) and only on the subsequent Ctrl+Click to the implementation.

"Seems like it's clearer to require the developer to explicitly choose (by picking one menu item or another) whether they want to see a type declaration or to view the implementation code."

Separate context menus are fine and good idea to have. They are not mutually exclusive to the Ctrl+Click behaviour.

Wonder why this critical bug is not being worked on yet. It is just becoming a more and more pain in the ass as typescript adoption goes up.

I don't want to hear technical explanations, I want to know why this issue isn't even acknowledged after so much description on different users.

@zjaml are you wanting it to go to TypeScript source files or JavaScript source files? TypeScript source files are supported. It's JavaScript source files that this issue is currently still open for.

Tangentially related; I have a monorepo with a common package that's published to npm. Because of this public interface the dist is js + d.ts files. When I'm working in the repo VSCode always jumps to the d.ts instead of the source. Do you know a way around this?

@0x80 I believe this issue is still open for the scenario you just described. The only way I think you could get around this is if the project is open source and you compiled it from the typescript source. Then you could turn on the --declarationMaps flag for the typescript compiler and IDEs that support the declaration maps will go to the typescript source instead of the d.ts files.

This is really crucial. I want simple thing: CTLR+Click and navigate to node_modules/library/source.js or source.ts file. Opensource project with 60 node_modules dependencies and you are back to using notepad with explorer.

When I right-clicked on a component I saw: "Go to Definition" and "Go to Type Definition". I thought "Great, this has been well designed, the solution to my problem is just here!". Then I clicked on "Go to Definition" and... landed to the Type Definition.

This is really crucial. I want simple thing: CTLR+Click and navigate to node_modules/library/source.js or source.ts file. Opensource project with 60 node_modules dependencies and you are back to using notepad with explorer.

+1
Same need.

With all due respect, the fact that this isn't implemented is incredible. Such a basic, relatively easy to
build feature that would save people tons of time.

With all due respect, the fact that this isn't implemented is incredible. Such a basic, relatively easy to
build feature that would save people tons of time.

+1

Well, in the meantime when this feature is not yet available, is there any better workaround beside searching for the whole node_modules ? It really inconvenience...
For example, I go to the definition and it led me to node_modules/@com.abc/sample/lib/core/internal/abc.d.tswhen the one I want is actually located at node_modules/@com.abc/sample/src/core/internal/abc.ts

@Happin3ss

is there any better workaround beside searching for the whole node_modules ?

The current solution AFAIK is declaration maps. These are sourcemaps that map .d.ts files to the corresponding TS source. If you can convince the libraries that you depend on to implement declaration maps (which I think effectively requires publishing .d.ts inside the library package as opposed to relying on @types) then you'll be able to automatically jump from your client code to the original TS (or even JS if using the TS compiler on JS?) source code.

What I've been doing is gradually filing PRs against my most important dependencies (at least the ones that are authored in TS) to get them to add declaration maps.

Obviously it'd be better if changing the library weren't required.

Another workaround (if changing the library isn't possible) works in the case where the library bundles .d.ts inside the package but doesn't have declaration maps. In that case, I'll use Go To Definition to get to the type declaration, then I'll click the Explorer button in VSCode to show the folder sidebar. That usually gets me very close to the src folder for the package, so instead of having to search through all of node_modules, I can just browse into the right folder and open the correct file. This is dependent on clear file naming, etc. and is not a panacea.

Just to be 100% clear-- I'd love to see a better solution for libraries, esp. those where .d.ts is authored separately from the package.

Not sure if I've missed it, but it would be really useful for understanding what's happening to have actual minimal examples of sources, declarations and declaration maps. I've never seen either Go to Definition, Go to Type Definition, or Go to Implementations actually go to anything but a .d.ts file for transpiled TS. I just tried to make a simple example, and it doesn't work; I can't get VS Code to go to anything but the .d.ts file, even though the .d.ts.map is next to it. I've also found someone else with the same issue who was ignored.

It's understandable that supporting external typings like @types would be hard, but what does it say that even the "happy path" can't be made to work?

There are many libraries that generate declaration files but not declaration maps, and it's unclear what the argument would be for enabling them. This option has been added without a clear explanation, at least one that I'd be able to find.

Yes, I confirm that declaration maps are not solving the problem. My project has got declaration maps but vscode does not navigate beyond .d.ts files.

It sure would be great if this happened.

if there is an "elephant in the room" of issues for ms vscode devs, this is it.

Any updates on this one?
I just decided to make a big step: move from JS to TS. I thought - "what am I doing wrong?" but actually, it's unexpected behavior of VSCode

Any updates on this one?
I just decided to make a big step: move from JS to TS. I thought - "what am I doing wrong?" but actually, it's unexpected behavior of VSCode

It was a long history since this behavior had been raised. Well, nothing going on here. No plan so far.
For me, I keep using vscode as a kind of editor as it is, and Intellij products (IDEA) for my coding stuffs even I don't like it so much.

Opened for 5 years, hope it will be fixed in 2025

I've created failing tests in #39426 but I don't know how to implement it

Just another miserable comment from ts dev going through hell everyday to find definitions

This is crazy... I thought I was just a TS noob, but now I see that the behavior I’m getting is actually “standard”???? So frustrating, every other IDE/language I’ve used has this implemented at initial release... :( I love VS code but honesty this could be a deal breaker

Can anyone explain why go to definition/implementation features in VSCode with Python extensions for, huh, Python language works better (it's works at least) then for JS having native built-in solutions?

So what is going on?
I am using scss.d.ts for css modules and can't jump to scss.

Also when creating simple .js and accordingly d.ts, I cannot jump straight to js

why not use webstorm?
it can solve this problem!!!
my version 2020.1

why not use webstorm?
it can solve this problem!!!
my version 2020.1

Because it's not open-source solution and not free

Please fix this.

It's absolutely clear, that this problem can be fixed only if some manager from Microsoft takes over, this problem has to be managed and coordinated, a manager develops a workflow and assigns work to coders. ☝
This problem has to be sent to the management to take over and they decide how it will be implemented.
So if is here somebody competent from Microsoft, he can give a shot. 😊