Enable Go to Implementation in Typescript Editors

Could you provide a way for Typescript Editors to list the implementations of a type?
This would definitely help developer productivity to be able to find implementations of types faster.
For example, in the Atom Editor atom-typescript plugin you can press F12 to 'Go to Declaration' which as currently implemented you often arrive at the typescript .d.ts file which has the function signature but not the actual implementation.
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 opened a similar request for the Atom-typescript editor, but they indicate that they cannot implement this without Typescript parser support:
TypeStrong/atom-typescript#790

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
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

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;
}

@robsman Go to Definition should take you to the compiled js code, while Go to Type Definition should take you to the ts file.
That issue still exists for me in VSCode 1.27.0, as both functions take me to the .ts file

@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 sits 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 on function in js file (if it's javascript) inside node_modules not .d.ts. Anyway I don't understand for what VSCode this feature in the current state

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

Maybe I'm missing something, but the way I see the default CMD + Click behaviour is:

if the .d.ts exist go there
if it doesn't exist go to the actual js file

right now I can't click to navigate to a .js file

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.

I cannot believe this is open since 2015, how do you guys conveniently navigate to implementation?

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 in TypeScript it seems they all do the same thing, 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<EMAIL_ADDRESS>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" -><EMAIL_ADDRESS>line 117
"Go to Type Definition" -><EMAIL_ADDRESS>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

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..

That is the case for me too, in "node_modules", Go To Definition and Go to Type Definition both send my to the *.d.ts file. The library is tensorflow

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!

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.

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".

 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:

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
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
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
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 as as typescript adoption goes up.

@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 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.

The funky code navigation is the only reason why I'm still using Webstorm. I come back to Vscode once in a while to check if it's fixed. But it's not.

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.

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<EMAIL_ADDRESS>when the one I want is actually located at<EMAIL_ADDRESS>

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.

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 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.

+1 For this feature

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

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 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!!!

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. 😊

+1, the absence of this feature makes it very difficult to be productive in a Typescript codebase. VS Code provides "Go to definition", "go to type definition", and "go to implementations". Currently, all three do what I expect from "go to type definition", and none of them go to the implementation.

+1, the absence of this feature makes it very difficult to be productive in a Typescript codebase. VS Code provides "Go to definition", "go to type definition", and "go to implementations". Currently, all three do what I expect from "go to type definition", and none of them go to the implementation.

Can it be fixed in 2021 ?

Can it be fixed in 2021 ?

Can it be fixed in 2021 ?
Based on my 4+ years experience following this issue, NO
My suggestion for you again, is change your IDE to Jetbrains's if that feature is essential for you (like what I did). Otherwise, just accept it as it's the down side for a free and opens source product 😄 Your voice is listened, but not always.

Can it be fixed in 2021 ?
Based on my 4+ years experience following this issue, NO
My suggestion for you again, is change your IDE to Jetbrains's if that feature is essential for you (like what I did). Otherwise, just accept it as it's the down side for a free and opens source product 😄 Your voice is listened, but not always.

I'm joining the party. Maybe in this case noise and jokes on GitHub are okay.
Any workarounds apart from manually navigating or project wide search?

I'm joining the party. Maybe in this case noise and jokes on GitHub are okay.
Any workarounds apart from manually navigating or project wide search?

Today, I got the latest VsCode update and it has become a bigger problem now. Now, When I do Go To Definition on a React Component, it goes to node_modules\@types\react\index.d.ts:547 for EVERY component.
I'm switching editors for typescript if this won't be fixed soon. This feature is highly needed, I use it hundreds of times per day.

Today, I got the latest VsCode update and it has become a bigger problem. Now, When I do Go To Definition on a React Component, it goes to node_modules\@types\react\index.d.ts:547 for EVERY component.
I'm switching editors for typescript if this won't be fixed soon. This feature is highly needed, I use it hundreds of times per day.
Edit: It seems to be a tradeoff, now it does go to definition instead of type definition with objects and if you go to definition on the import of a component, it does show the implementation instead of the type. So it's still workable but it also still needs more improvement.

yes is VERY ANNOYING,
i want to go to component declaration and not the type definitions
vscode older version was working

Today, I got the latest VsCode update and it has become a bigger problem. Now, When I do Go To Definition on a React Component, it goes to node_modules\@types\react\index.d.ts:547 for EVERY component.
I'm switching editors for typescript if this won't be fixed soon. This feature is highly needed, I use it hundreds of times per day.
Edit: It seems to be a tradeoff, now it does go to definition instead of type definition with objects and if you go to definition on the import of a component, it does show the implementation instead of the type. So it's still workable but it also still needs more improvement.

Did you manage to find a way to go to proper definition? I'm using react and whatever piece of imported code I try to get the definition of, it no matter what sends me to<EMAIL_ADDRESS>

@wtfzambo I use goto definition on a variable that is not in JSX and it works most of the time (like the import statement or somewhere else in the file). But clicking a component name in a  JSX part leads me to<EMAIL_ADDRESS>

@ThaJay ah crap, nvm then, I have everything in JSX so I guess I'm out of luck for the time being >.<

@ThaJay @wtfzambo Just click on the component once in the editor, then press CMD + F12. Best workaround for the time being.

@andrewmartin I tried that, but it still sends me to index.d.ts. See:
==>
But then at this point I'm thinking I am not fully understanding how this whole thing works, since coming from python, if I F12 upon anything I'd just get sent to the source code of whatever I'm using.

The one of must have features of each IDE is 6 year in backlog still?

@andrewmartin Thank you, I understand now.
Nice that it has been fixed. On to the actual question then, I want to set my ctrl+click gesture to goto implementation and ctrl+f12 shortcut to goto definition.
There does not seem to be an option to change the command for the ctrl+click gesture.

@wtfzambo it looks to me like you're trying to go to the definition of a <div> element. <div> comes from React. Try putting your cursor on the word <Navbar /> in the consumer (wherever you use Navbar in your app), then press CMD + F12.
@Zx-EvM this worked fine before and still technically works. Just need a way to configure the CTRL + CLICK gesture as @ThaJay just mentioned. I think it may be possible actually, so I'm digging in a little more...

@andrewmartin you're right sorry, I should have been more specific. It works for custom components (such as my <Navbar />) but it doesn't work for stuff that I import from node_modules.
But I guess I was expecting a python-like behavior that in JS is not really a thing, as one of my colleagues explained to me.

@wtfzambo - my understanding is that when sourcemaps are involved (as they will usually be for imports from node_modules) then declaration maps are also needed in addition to sourcemaps. A "declaration map" enables connecting a TS declaration to the implementation, even if the implementation is in JS which is sourcemapped back to TS.
See https://stackoverflow.com/questions/58459988/what-is-the-use-case-of-enabling-declaration-and-declarationmap-in-tsconfig-json for details.
Relatively few npm packages have declaration maps enabled. ;-(

@andrewmartin cmd+f12 (Go to implementations) does not work for me, it still takes me to the type definition file or just says "No implementations available" . Is there another setting that needs to be configured to make this work?

So, this is the reason why this works when a file is named source.js (it brings me to the definition)

And does not when it is called source.ts?
Really, after 7 years!

So, this is the reason why this works when a file is named source.js (it brings me to the definition)

And does not when it is called source.ts?
Really, after 7 years!

what is the reason exactly?

But I guess I was expecting a python-like behavior that in JS is not really a thing, as one of my colleagues explained to me.

It should be a thing. If it's not a thing (it usually isn't) then that's because of things not working like intended. I had a js project once where it all worked and it was glorious.

Can confirm this is very annoying. "Go to definition" in VSCode works same as "Go to type definition"

I'm not sure if this case is about jumping to the compiled JS or the original TS file, the former I see as being less useful. Usually I want to jump to the TS source file instead of the generated d.ts.

I'm not sure if this case is about jumping to the compiled JS or the original TS file, the former I see as being less useful. Usually I want to jump to the TS source file instead of the generated d.ts.

The ideal behavior would be for the IDE to navigate to the "original source", meaning the file pointed to by the sourcemap of the transpiled JS. Sometimes this will be a TS file, sometimes a JS file that's been transpiled, or could even be some other language that's been transpiled down to JS.
I agree that showing the transpiled JS is not as helpful, and could be actively confusing for some transpilations (e.g. of async/await) which are more-or-less incomprehensible for newbies... and sometimes for experts too!

Is there anything blocking a community extension to get around this issue?

I'm not sure if this case is about jumping to the compiled JS or the original TS file, the former I see as being less useful. Usually I want to jump to the TS source file instead of the generated d.ts.

I just want to go to exactly the place where the import points. Nothing else is even remotely interesting compared to this dead simple link. If the one file says import {Foo} from ../Stuff and I follow Foo, I want to go one folder up, into the file Stuff and highlighting the line that says export Foo.
It seems quite simple and I rather not have typescript at all than this not working.

GitHub UI supports click to jump to implementation OR type definition. I wonder what trickery they are using...

I might soon ditch VSCode in favor of Github UI then😄
On Tue, 21 Sep 2021 at 10:53 Mikael Finstad @.***>
wrote:

GitHub UI supports click to jump to implementation OR type definition. I
wonder what trickery they are using...
[image: Screenshot 2021-09-21 at 12 50 52]
https://user-images.githubusercontent.com/402547/134118734-3dd264fc-1542-4ed1-b191-ac3342af21ea.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/TypeScript/issues/6209#issuecomment-923650713,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGZIA5D4ONECWWXGDBKXSQ3UDAMVTANCNFSM4BXI277A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Is this ticket not in the right place?
Is everyone else happy manually trawling through node_modules every time they want to look at an implementation or is there something I'm missing?

Is this ticket not in the right place? Is everyone else happy manually trawling through node_modules every time they want to look at an implementation or is there something I'm missing?

No, you're not missing anything, everybody is indeed very unhappy with the current situation (there's 100 hidden items above)

Every project has tickets like this @publicvirtualvoid that is absolutely normal, I can name 10 tickets like this right away right now in other projects 😂, maybe not 10 right now, but you know what I mean 🙂

@silverqx at least maintainers in other projects have better outreach (ie Flutter, even with all its issues). If they could explain their rationale and all the technical roadblocks, I'm sure the community could help in some way. It's been six years already for such a fundamental feature though, so a solution is probably never coming. It's a pretty embarrassing situation for their team to be in tbh.

@sabetAI  I think the reasonable explanation is that go to implementation has nothing to do with typescript, and as a typescript team they definitely want everyone use typescript, so they has less willingness to improve the javascript user experience.

I'm happy to see continued enthusiasm for solving this problem. Keep the upvotes and (especially) constructive suggestions and PRs coming! Like many hard things, eventually I'm sure we'll help to get a solution built for this annoying gap in the TS developer experience.

@sabetAI I think the reasonable explanation is that go to implementation has nothing to do with typescript, and as a typescript team they definitely want everyone use typescript, so they has less willingness to improve the javascript user experience. Actually if you delete all the type declaration files go to implementation works.

As far as I can tell, this impression is not correct. Almost all* packages that are written in TS, transpiled to JS, and published to npm don't work with "Go To Implementation" any more than packages originally written in JS.
I said "almost all" above because there is a way to make it work: using the declarationMap tsconfig compiler option.  But:

This setting is not enabled by default.  IMHO it should be enabled by default whenever sourceMap is enabled. (Maybe also when inlineSourceMap is enabled?)
There is AFAICT no evangelism from the TS team (or anyone else!) about how package authors should enable this setting and include declaration map files when publishing their packages to npm.
There's also no push to get declaration map files into existing DefinitelyTyped packages. Could this be automated instead of relying on 1000s of type-package maintainers to do it?

Anyone who wants to see this problem get better could:

Send a PR to try to change the default of declarationMap to be true if the sourceMap or inlineSourceMap option is true. This minor change would probably have the biggest impact on this problem over time.

Send a PR to update the TS docs to be more vehement that declarationMap should be enabled for all library packages, and explaining why ("because "Go To Implementation" in VS Code relies on declaration map files"). These documentation changes will be crucial if (1) is not approved.

Send a PR that adds or extends the TS docs with specific guidance for package authors, including "publish your sourcemaps" and "publish declaration maps".

Write a tool that will automatically add declaration map files to all compatible DefinitelyTyped packages, and convince the DefinitelyTyped maintainers to merge the output of that tool into every compatible DefinitelyTyped package.  Part of the work would be figuring out what "compatible" means and what packages' declaration maps can't be automated.  Note that @weswigham above was pessimistic that this automation would be possible. But I wonder if things have improved since then to make automation possible? Or if it'd be possible for a large subset of packages? Here's what he said:

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.

Send a PR to change the build actions for DefinitelyTyped to warn users if they try to add a new package that lacks a declaration map.  Not sure if this is something that can be done outside the DT maintainer team, depending on how the existing DT toolchain works. Someone who knows DT better than me could answer this.

The community has agency!  If we want things to get better, any of the items above can make things better.
There's also IMHO another confusion with "Go to Definition" vs. "Go To Type Definition" are implemented. My preference would be for "Go to Type Definition" to navigate to the types and "Go to Definition" to navigate to the implementation. Not sure this is worth changing community expectations, though, given how long the current behavior has been in place. For more details, see: https://github.com/microsoft/TypeScript/issues/6209#issuecomment-525911553

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".

@weswigham - sorry for delayed reply, I just opened #46627 for this.

Thanks @justingrant! I want to make a few observations.
If I understand correctly, the thing in highest demand here is to be able to jump (whether as an explicit action or automatically under the hood as part of an existing UI action) from a location in a .d.ts file to a location in a .js file (and perhaps a .ts file is also an acceptable target for some people if it exists). The declaration maps and source maps generated by the TypeScript compiler allow you to jump from a location in an output file (.js or .d.ts) to a location in an input file (typically .ts, but could be .js).
On top of this, I’ll add some assertions that I think most people would agree with:

Most npm libraries written in TypeScript do not publish their .ts sources to npm; they publish only the .js and .d.ts outputs.
DefinitelyTyped packages often do not track versions 1:1 with their implementation libraries; DT is updated asynchronously by volunteers, and furthermore, many patch version bumps of the implementation libraries do not require updates to DT as these patches typically don't change the public API surface.

Putting all this together, I can draw a few intermediate conclusions:

Even if it were possible to auto-generate declaration maps for DefinitelyTyped, it would not be practical because the chances are extremely low that any user who obtains that declaration map would have the exact version of the implementation library that it was generated against. Every time the implementation library changes anything, even just adding a newline somewhere, the DT package would have to be regenerated against that source, and users would have to update them in lockstep or else they’d get sent to an inaccurate file / line number. This is a total non-starter.
Turning our attention away from the DefinitelyTyped problem and toward libraries written in TypeScript: enabling and shipping declaration maps alone would not change anything; those libraries would need to ship the declaration maps and the .ts source files in order for us to use the declaration maps. If libraries started doing that, we could easily jump from the .d.ts to the .ts (or skip the .d.ts altogether—maybe this is already what happens?). Even in that case, though, we would have no way of getting to the .js source. I think some people would be happy just to see the .ts source, but I can also imagine pushback at the idea of making the world download TypeScript source files from npm just to light up an editor feature. I think more people would be just as happy or happier to be able to go to the .js and leave the .ts out of their node_modules. But nothing we’ve discussed so far is remotely useful in making this happen.

Because of these problems, I’m actually a little confused at the focus of this issue on declaration maps. It seems like they would help only in edge case scenarios, and I think I can categorically reject the idea that we could use them to map from DefinitelyTyped to another source. The only solution I can think of that could solve both the problem both for DefinitelyTyped and for bundled type definitions is for us to make an effort to find, parse, and bind the corresponding JS file and make an effort to find the symbol in question. This would surely fail in the face of highly dynamic or unusual JS patterns, or where .d.ts files don't cleanly map 1:1 to .js files. It could also be expensive in the face of huge bundled and minified files. This would have to be understood as a heuristic-based best effort, and perhaps a worst-case fallback would be to take you to the top of the package’s "main" (or relevant "exports") file. But I also suspect that this process would work perfectly for a lot of libraries, and personally, I think just opening up the "main" entrypoint would save me time over scrolling through hundreds of node_modules folders when I really need to track something down in the source.

Hi @andrewbranch - thanks for jumping in on this important issue. After following it for a few years, I'll add context that may help.

My understanding is that Go To Implementation currently works, but only for packages that publish their .d.ts, sourcemaps, declaration maps, and original sources to npm. Unless I'm mistaken, packages that are compiled with TS (an increasing number of popular packages!) can make Go To Implementation work today.

Caveat: TSC may emit declaration maps that work, but popular transpilers and bundlers (rollup, esbuild, babel, etc.) may not. rollup-plugin-ts has problems, and I suspect others do too. If the TS team could help those maintainers fix their support, the ecosystem would be hugely grateful!

Increasingly, maintainers are packaging original sources, because original sources (or inline sourcemaps) are required for easier debugging in browser dev tools and IDEs like VSCode.

This is especially true for the increasing number of popular packages that are being ported to TS.
I've pushed PRs to fix sourcemaps and ship original source for 10+ packages. If my memory is correct, only once has a maintainer refused to ship source. The others were happy to ship source because it helped their users debug their package more easily.
There are ecosystem changes coming (e.g. to create-react-app, perhaps later to npm publish) that may accelerate the trend of shipping original source along with sourcemaps.

Transpiled JS is often hard to understand, esp. for async/await or other ES6+ features that don't transpile cleanly to ES5. For this reason, the VSCode debugger's Step Into (the debugger counterpart of Go To Implementation) always only shows transpiled JS if the original source is unavailable. Seems like Go To Implementation should behave the same way, both for consistency across different ways of "navigating" and also because many users are confused by transpiled source.
You're 💯  correct that DT won't work with declaration maps because of version mismatches. My fault for not thinking this through before posting.

I'm seeing many package maintainers bundling their .d.ts with their packages to avoid versioning mismatches, or because they're porting their source to TS. There's still a lot of reliance on DT, so this trend doesn't invalidate the need for a DT-friendly solution. But it also suggests that the non-DT (bundled declarations) case is important too and will get more important over time.

For all the reasons above, I suspect that the right solution is two-tracked:

For packages built with TS, packaging declaration maps (along with sourcemaps, .d.ts, and original sources) seems like a good solution, because it can provide granular, precise navigation that I'm not sure is possible with an exports-only solution. I assume it'd provide the best perf too. Also it actually may work today!  But...

We're lacking guidance for package maintainers about how to make declaration maps, sourcemaps, etc. work correctly. IMO, what's needed is general ""how to build a library in TS" docs. Here's a possible outline for this content.
As noted above, non-TSC bundlers and transpilers probably need help with emitting declaration maps properly because today those maps can be broken by code splitting, tree shaking, etc.
Consider defaulting declarationMap to be true if the sourceMap or inlineSourceMap option is true
For packages with inline sourcemaps, can we use the same code that the JS debugger extension uses to show "sources" using inline sourcemaps?

For packages that aren't built with TS (or where the declaration map => sourcemap => original source chain is broken), there should be a fallback solution.  For example assume the following code:

// mode_modules/some-package/src/Foo.js
import doSomething from 'do-something';
class Foo {
  static bar(x) {
    doSomething(x);
  }
}
export default Foo;

// mayapp.ts
import Foo from 'some-package';
const x = Foo.bar(42);

I assume that Go To Implementation for import('some-package').Foo.bar  should behave as follows:

If the location of bar can be resolved, e.g. via sourcemaps or some TS JIT magic, then navigate to static bar(x) {
If all we know is imports, then navigate to class Foo { (I'm assuming that the same magic that the IDE uses to make Go To Definition work for regular JS files will also work as long as  Foo is declared at global scope.)
If all we know is the file (e.g. if package.json has exports) but the exported symbol cant be resolved in that file, then navigate to the first line of Foo.js
If we don't even know the file then navigate to main or module.

The bullet-points above are pretty hand-wavey because I don't know enough about TS and Node's module-resolution behavior. But I assume TS and/or Node-resolution experts will know what's possible!
@andrewbranch what do you think?  You likely understand this stuff better than I do, so please correct me where I'm wrong above.
Why navigating to transpiled source is bad

I think more people would be just as happy or happier to be able to go to the .js and leave the .ts out of their node_modules.

Are you sure about this?  Have you heard this sentiment from median-skill developers?  I'm skeptical, because transpiled code can be really hard to understand for non-advanced developers.
For example, here's an example of the code I saw in VSCode when I first debugged into a method of AWS Amplify, Amazon's JS front-end library that wraps AWS services:
           onSuccess: function (session) { return __awaiter(_this, void 0, void 0, function () {
                var cred, e_1, currentUser, e_2;
                return __generator(this, function (_a) {
                    switch (_a.label) {
                        case 0:
                            logger.debug(session);
                            delete user['challengeName'];
                            delete user['challengeParam'];
                            _a.label = 1;
                        case 1:
                            _a.trys.push([1, 4, 5, 9]);
                            return [4 /*yield*/, this.Credentials.clear()];
                        case 2:
                            _a.sent();
                            return [4 /*yield*/, this.Credentials.set(session, 'session')];
                        case 3:
                            cred = _a.sent();
                            logger.debug('succeed to get cognito credentials', cred);
                            return [3 /*break*/, 9];
                        case 4:
                            e_1 = _a.sent();
                            logger.debug('cannot get cognito credentials', e_1);
                            return [3 /*break*/, 9];
                        case 5:
                            _a.trys.push([5, 7, , 8]);
                            return [4 /*yield*/, this.currentUserPoolUser()];
                        case 6:
                            currentUser = _a.sent();
                            that.user = currentUser;
                            dispatchAuthEvent('signIn', currentUser, "A user " + user.getUsername() + " has been signed in");
                            resolve(currentUser);
                            return [3 /*break*/, 8];
                        case 7:
                            e_2 = _a.sent();
                            logger.error('Failed to get the signed in user', e_2);
                            reject(e_2);
                            return [3 /*break*/, 8];
                        case 8: return [7 /*endfinally*/];
                        case 9: return [2 /*return*/];
                    }
                });
            }); },

Eek!  I assume that most JS developers won't easily understand happening in the state machine above. But after https://github.com/aws-amplify/amplify-js/pull/2680 was merged, debugging into the same method showed the original source, which is much easier to understand:
			onSuccess: async session => {
				logger.debug(session);
				delete user['challengeName'];
				delete user['challengeParam'];
				try {
					await this.Credentials.clear();
					const cred = await this.Credentials.set(session, 'session');
					logger.debug('succeed to get cognito credentials', cred);
				} catch (e) {
					logger.debug('cannot get cognito credentials', e);
				} finally {
					try {
						// In order to get user attributes and MFA methods
						// We need to trigger currentUserPoolUser again
						const currentUser = await this.currentUserPoolUser();
						that.user = currentUser;
						dispatchAuthEvent(
							'signIn',
							currentUser,
							`A user ${user.getUsername()} has been signed in`
						);
						resolve(currentUser);
					} catch (e) {
						logger.error('Failed to get the signed in user', e);
						reject(e);
					}
				}
			},

I agree that there are some cases where sophisticated users may want to see the transpiled JS. But those are unusual cases. The normal case (and the only case that many unsophisticated developers can handle) is to show the original source, for the same reasons that we show original source in the debugger.

But I also suspect that this process would work perfectly for a lot of libraries, and personally, I think just opening up the "main" entrypoint would save me time over scrolling through hundreds of node_modules folders when I really need to track something down in the source.

I think you are correct here. It doesn't have to be perfect to add a lot of value.

Thanks for the detailed explanation, and all good points. I don’t doubt that publishing TS sources to npm for debugging purposes is becoming more common. Likewise, as you also noted, we’re seeing a slow but steady trend of packages moving away from DefinitelyTyped to ship their own types (presumably most of these are autogenerated from TS sources, but some are hand-authored or generated from a tool other than tsc). However, I feel confident that the majority of people’s node_modules today lacks TS implementation files, so any solution that does not include an attempt to resolve symbols to JS, at least when no other option is present, I think will be highly unsatisfying and confusing.

Are you sure about this? Have you heard this sentiment from median-skill developers? I'm skeptical, because transpiled code can be really hard to understand for non-advanced developers.

Nope! This was a total guess based on past experience with JS-only VS Code users who get confused (and sometimes angry 😅) when they get dropped into something that looks TypeScripty. I think there are users who would rather get dropped into the JS, but at this point I don’t have evidence to say they make up a particular ratio of all users. But, I don’t think it really matters—if we have all the pieces in place to jump to the exact right place in a .ts file, we can be nearly 100% sure that result is correct and we can calculate it very fast, so I think we should always do that. The point I should have been making was, again, that we need to be able to make a guess at the JS when the TS doesn’t exist.
I guess my thought process was, if I need to look at implementation files in node_modules, something has already gone horribly, horribly wrong, and I’m bracing for a bad time. I hopefully don’t need to fully understand generator downleveling in order to find a line to put a breakpoint on. But I’m sure my standards here are too low for long-term thinking 😄. It seems like you’re doing a very good job of thinking about how to improve things for the long game, which I very much appreciate. I was admittedly more focused on how to get acceptable results now. Point well taken that we should be thinking about both. It’s probably worth at least doing some writing about the benefits of publishing declaration maps and sources with your packages.

The bullet-points above are pretty hand-wavey because I don't know enough about TS and Node's module-resolution behavior. But I assume TS and/or Node-resolution experts will know what's possible!

I actually don’t think we know what’s possible without some experiments. My suspicion is that exports will usually be easy, and drilling down into them further will be hit-or-miss, but I don’t know.

Cool, sounds good. A few responses inline. So glad you're looking into this!

Nope! This was a total guess based on past experience with JS-only VS Code users who get confused (and sometimes angry 😅) when they get dropped into something that looks TypeScripty.

Yep. Those users have a difficult tradeoff: hard-to-read transpiled code or also-hard-to-read (for them) TS code. But this is exactly the same problem they have in the debugger today, and debugging into node_modules is much more common than using Go To Implementation for node_modules.
For this reason, I'd recommend thinking of these problems separately.

How can Go To Implementation show original source (from source/declaration maps) with a fallback to transpiled JS if the mapping doesn't work. The default will be "original source" because that's consistent with how (more common) debugger use cases behave.
How to easily flip from transpiled source to original source (and flip back too) in the IDE?  This would affect the most common case (the debugger) as well as less common cases like Go To Implementation. FWIW, when debugging I frequently have cases where I want to view transpiled source (e.g. when I suspect the sourcemap is out-of-date after a hot reload) so this feature would be useful beyond TS haters.  The UI could be a right-click command, or even a button in the upper-right-corner toolbar like the button used to navigate from a diff view to the underlying file.

I think keeping the problems separate will make it easier to make progress on both in parallel without getting stuck in arguments about whether to show TS or JS for Go To Implementation.
Question: do declaration maps that TSC emits point to transpiled code or to original source?  If the former, then they'll work just like the debugger. 👍  But if the latter, then it seems like it'd be hard to find the transpiled JS. I guess TS could load the entire sourcemap of the package and see if the file/row/col that was resolved by the declaration map also shows up in a sourcemap file, and trace it back from there?  Anyway, it'd be good to know whether declaration maps point to transpiled or original source.

if we have all the pieces in place to jump to the exact right place in a .ts file, we can be nearly 100% sure that result is correct and we can calculate it very fast, so I think we should always do that. The point I should have been making was, again, that we need to be able to make a guess at the JS when the TS doesn’t exist.

👍  Yep!  I come back to aligning with the (more commonly used for node_modules navigation) debugger behavior: if there's original source, show that. If not, then try to fall back to something reasonable.

if I need to look at implementation files in node_modules, something has already gone horribly, horribly wrong, and I’m bracing for a bad time.

Many years ago, I was working with the VS team back when the original "Just My Code" feature was being built. There was a big debate between the C# and (especially) the C++ team whose users had a long history of viewing, debugging, and copying libraries like MFC vs. the VB team whose users were confused by library code, esp. because libraries were written in C# and C++!  What's nice is that both preferences have been improved. For library-code-haters, Just My Code continues to exist and be enhanced. For library-code-lovers, it's gotten easier to view, debug into, and modify library code.
But the fact that 15 years later this debate hasn't gone away is a signal that this is a persistent difference between developers. For some devs, viewing library code is an awful, exceptional case. But for many other users, debugging, viewing, and even editing/PR-ing library code is a normal course of business, because libraries are often buggy, poorly documented, or need to be extended in some way.  You see this parallel in other walks of life too. For example, if a light switch isn't working, some folks will grab some tools while others will grab a phone and call an electrician.
So I think it's helpful to assume that for many developers (but not all!) they will read, debug into, fix, and borrow library code frequently, so we should try to make it work as well as possible.
For Just My Code fans, they won't be clicking Go To Implementation anyways (because their preference is to avoid library code!) so I think this feature is really targeted only at the anti-JMC crowd.

exports will usually be easy, and drilling down into them further will be hit-or-miss, but I don’t know.

Yep, I think the same.

It’s probably worth at least doing some writing about the benefits of publishing declaration maps and sources with your packages.

What are next steps to get more attention on this?  In https://github.com/microsoft/TypeScript/issues/16792#issuecomment-892068076 I wrote a possible outline for this content. I'm happy to help contribute but honestly I feel unqualified to write it because I don't understand enough about the problem space. But I'd love to pair with someone to help make this content happen. LMK how I could help.
A good place to start might be to simply creating a "Writing libraries in TypeScript" section in the docs and putting some minimal content there. Then that section in the docs could be a honeypot to attract tips and tricks from various TS library authors via PRs. In addition to sourcemaps/decl-maps content, there could be sections about how to configure various bundlers, how to migrate from DT to shipping types, and other topics that only apply to library authors.

So one thing I haven't seen mentioned, though I may have missed it in this long thread, I miss seeing the actual code comments, function & parameter descriptions. Sure types are great, but knowing the package authors intention for each function is almost more valuable.
date-fns for example doesn't tell you in their .d.ts files which date is supposed to come after the other for functions like isAfter. The answer is clear in the functions actual Docblocks. And digging into a large node_modules folder to find that one js file is tedious when you need to do it a dozen times.
What VSCode gives me:

What the package authors intended me to see:

@danieliser totally agree—however, if we get a solution to this at all, it’s likely to be a “best guess” effort to find the corresponding JS from the typings. I’m ok with providing a go-to function for that because it’s better than nothing, but I don’t think we’ll achieve high enough confidence (or satisfactory performance) in that guess in order to pull in the JSDoc. This seems like a case where the answer is just to get the package authors to copy the JSDoc comments to the typings (or copy it in a DT PR). If the typings are generated from TS source, the comments will be copied to the typings automatically. If they’re missing, it means someone’s manual process or third-party tooling is insufficient and the problem should be addressed there.

Please note the milestone change means I plan to investigate solutions to this during the 4.7 timeframe. I don’t think we have a clear path yet, so it doesn’t necessarily mean that something will ship in 4.7.

I'd like to add a use case: some of our files are authored as .js files (with JSDoc style typing) with explicit/manual .d.ts files for them to express things that cannot be expressed otherwise in JSDoc (e.g. circular type definitions, function overloads, interface, etc.)
The problem is that with such files, it's impossible to "go to definition" / "go to implementation" as VS Code and other editors stop at the .d.ts file. declarationMap isn't an option since the .d.ts file is manually authored.

I have a prototype up at #48264 that I’m welcoming feedback on. I’m 100% sure it doesn’t cover everything but if folks are willing to give it a try, it would be helpful to gather some test cases that don’t work yet so I can see if there’s a good way forward on them.
To try it: There’s a build from @typescript-bot on the PR (copied below) that you can npm install, then ensure your VS Code window is using that build of TypeScript by opening the command palette (in a TS or JS file) and running TypeScript: Select TypeScript Version. You should see the one newly in your node_modules listed as version 4.7.0. At that point, your Go To Definition command will be replaced with the new logic that finds more JS files and ignores .d.ts files. 🚨 This is not the final experience! We are not replacing Go To Definition like this! We don’t know for sure yet where the new logic will be exposed: it might be in a new command, or its results might be merged into Go To Definition or Go To Implementation. There are technical and UX reasons why the latter might not be desirable, but if it’s in a new command, none of you would be able to test it right now without also running a custom build of VS Code. So this build temporarily replaces the existing go-to-def implementation with the new command so you can easily test it.
One specific thing to keep an eye out for in testing: There are some cases where we are quite confident in the results we return, other cases where the best we can do is jumping to the top of a file, and then other cases where we’re confident about the file but we make a number of guesses within the file. Under the hood, I am indicating whether or not the result is a guess or not, but this information isn’t currently exposed in VS Code. If we go forward with presenting guesses like this, it will almost certainly go along with some kind of visual indicator noting that it’s a guess. Here’s an example on import { add } from "lodash":

Two of these guesses are right, while the top one is wrong. If you notice more places containing wrong guesses like this, please note that and tell me how to repro them on the PR. I need a bit of crowdsourcing to determine whether the guesses are worth doing at all and if there’s an easy way to improve them.
Thanks all!

Hey @andrewbranch, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:
{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/121842/artifacts?artifactName=tgz&fileId=BC8F78CBCF3D3B551A34EA6659FA5D670D458543ADE83DD287314B98C2CEFF7A02&fileName=/typescript-4.7.0-insiders.20220315.tgz"
    }
}

and then running npm install.

The plan is to add an experimental new command in VS Code to trigger the behavior added in #48264. I’ll keep this thread updated to let you know when you can try it out in VS Code Insiders + typescript@next.

Great progress here. Thanks @andrewbranch for your perseverance in making this happen!  Can't wait to try it out.

I’ll keep this thread updated to let you know when you can try it out in VS Code Insiders + typescript@next.

I forgot 🤦♂
You can try this in VS Code Insiders and typescript@next! And pretty soon it will be in the stable versions. I started an issue to gather feedback: #49003. Thanks!

Already in the newest release: Visual Studio Code April 2022

@andrewbranch Thank you thank you thank you for making this happen! You just made my life so much easier


check and rebase our forked taps/targets

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/775
Originally created by @dmor on 2019-07-10 14:42:06

As Singer continues to make improvements, we need to keep up with
tap-stripe already has several updates we could take (not breaking)
Recommendation from @iroussos is that we check for updates every month or so, and create issues for any updates that need to be integrated
We are currently forking taps and targets, but this might need to change in the future. Right now we don't support Oauth so we have to create our own authentication service, but right now we don't have it.

View 2 previous comments from the original issue on GitLab


Fix linting

Restored this branch as this should have been merged into dev, not master.

This has now been replaced by #35 which merges this to dev, as originally intended.


[GroversAlgorithm] Emphasize global phase in "Conditional phase flip" task

Context
GroversAlgorithm kata has a task "Conditional phase flip", which asks the learner to "Flip the sign of the state of the register if it is not in the |0...0⟩ state.". However, the reference implementation flips the sign of the state if it is in |0...0⟩ state, i.e., implements that transformation up to a global phase of -1. The hint in the task suggests that these two transformations are equivalent, and the tester checks unitary equality up to a global phase.
This is fine if this implementation is used for Grover's search algorithm itself, since the global phase will remain global and not be observable. However, if this implementation is used as a building block for other algorithms, in particular quantum counting algorithm, which converts the global phase difference into the relative phase, this can cause very interesting bugs (see an extended discussion in this Quantum Computing SE question).
Improvement
I would leave the testing harness as is (since for the purposes of Grover's algorithm both implementations are correct!), but put in a bit of effort into clarifying the difference and where it can come into play; so modifying the hint (and in the matching notebook) to explain that for the purpose of Grover's algorithm these transformations will be the same, but if you're using it for something else you'll need an exact implementation.
I'd also modify both reference solutions to include a comment along the lines "To fix the global phase difference, use the following line" and a line that uses the R gate to add the right global phase. This way the reference solutions would implement the exact transformation.

Raising a new PR due to git issues

Recreating a new PR due to git issues


Detect boot mode based on image file

Signed-off-by: David Cassany<EMAIL_ADDRESS>

image file is always passed as a parameter to the kernel cmdline arguments and image file names are statically defined constants. This is just more reliable than checking labels.


Create ru.json

Added full translation into Russian

Thank you 👍
I will add this to the next release

Closes #662


Allow user to copy information from graphic label created in Distance and Direction Widget

The D&D widget renders graphic labels after a shape is drawn. The labels have information about the shape that was created (ex: length, angle, radius). Provide the ability to copy/past those labels.

This issue was moved to Esri/solutions-webappbuilder-widgets#725


Fix issues #422 and #479

[FIX] :  Fix issue #422
with this implementation, now DataFrameClient allow to push DataFrame with null values (NaNs or None)

Issue: DataframeClient fails to push DataFrame with NaNs
Root cause : null are not allowed on Influx (null is not a valid type)
Possible work around: push column per column (with dropnan() before each push)
Solution : corresponding points are dropped from the list of points pushed to influx. Also takes into account full lines with nulls and DataFrame full of nulls)

[FIX] : Fix issue #479
conversion of DatetimeIndex to epoch was not correct on some machines.

Issue : on some Windows machines, DatetimeIndex not correctly converted to epoch
Root cause: to convert to Epoch, timestamp is first converted to int. On some machines, default conversion to int leads to a conversion to int32 (which lead to incorrect conversion to epoch). Conversion to int should be to int64.
Solution: conversion forced to int64 in the code

In commit f40f77065ca49334db3e3f587673d3844d925f37 you use dropna() but this method seems to delete all the row (https://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.dropna.html).
Maybe I'm wrong but I use this code to drop NaN values : df.fillna('') instead of dropna().

Closing stale request, addressed in later release.


desktop-app install fails on Linux

>>> desktop-app install dycall
Traceback (most recent call last):
  File "/home/demberto/.local/bin/desktop-app", line 8, in <module>
    sys.exit(main())
  File "/home/demberto/.local/lib/python3.8/site-packages/desktop_app/__main__.py", line 50, in main
    install(module, path=args.path, verbose=not args.quiet,
  File "/home/demberto/.local/lib/python3.8/site-packages/desktop_app/shell.py", line 264, in install
    create_desktop_file(
  File "/home/demberto/.local/lib/python3.8/site-packages/desktop_app/linux.py", line 41, in create_desktop_file
    path.write_text(dedent(contents), encoding='utf8')
  File "/usr/lib/python3.8/pathlib.py", line 1255, in write_text
    with self.open(mode='w', encoding=encoding, errors=errors) as f:
  File "/usr/lib/python3.8/pathlib.py", line 1222, in open
    return io.open(self, mode, buffering, encoding, errors, newline,
  File "/usr/lib/python3.8/pathlib.py", line 1078, in _opener
    return self._accessor.open(self, flags, mode)
FileNotFoundError: [Errno 2] No such file or directory: '/home/demberto/.local/share/applications/dycall.desktop'

Damn, I will check this tommorow for sure


Add pyright, fix pytest call, strict type check for setup.py

I didn't find a way to configure pyright in setup.py, opted to use a pyproject.toml instead of a pyrightconfig.json.
With pytest-xdist commented out passing -n auto errors out. Commented out the parameter, but probs cleaner to uncomment both lines or remove both.
Could opt to explicitly list files to avoid checking setup.py instead of adding the check for __version__ in it.

All checks are for stuff I didn't touch in this pull request, opening another one that works on flake8_trio.py and adds basic tests.

pyright config lgtm, discovery is less error-prone than explicit lists
let's leave xdist commented out for now; we'll uncomment once we have ~10 tests and concurrency is worth the overhead
obvious test failures are obvious, feel free to fix them here or in another PR as you prefer.

kk, let's just do that here then.
I haven't delved into understanding the testing setup that bugbear uses, so just doing basic tests for now.

Okay, cribbed bugbear's testing setup. Had to replace the namedtuple+partial solution to get it to pass pyright, though likely possible to get a cleaner solution.
Dropped stdin support for the filename parameter that bugbear had, was way too much of a hassle to get that covered and I'm not sure how big the need for it is.
I've never done fuzz tests before, but copy-pasted to my heart's content and they seem to do something.
Added back xdist since fuzzers started taking time.

fixed all comments, code starting to look pretty :sparkle:


Make JSON Sendable

Sendability is getting more and more present in Swift.
This PR adds conformance to the Sendable protocol to JSON when the compiler version is >=5.5. There is nothing else to do AFAICT as JSON was already Sendable.

Closing as this project is not maintained anymore. I have implemented correct Sendability in my fork.


Make it possible to download a differential update to the DB

What would you like to be added:
When grype decides to update the vulnerability database before a run, grype should be able to download a diff of what changed, rather than the entire database.
Why is this needed:
Right now, when running grype for the first time that day, ~130MB download is needed for the new Grype DB. However, it is very likely that most of this data was downloaded the day before, with only a small number of additions and subtractions. It would be great if only this tiny diff could be downloaded each day, instead of the entire database.

this kind of feature can be helpful (know when a record was updated)


Merge auth_roles_test.py into auth_test.py

@mambocab to review

In principle, this merge is fine for now, but at some point we should have a more detailed look and separate these out into submodules in a single folder.

Execution looks good too. I'm +1 on the changes; please either make those lists namedtuples or file a JIRA for us to do that in this sprint.

Filed and assigned to myself.


Increase coverage of Slicey

schweeet! :candy:

Looking really good. :)

Bingo bango merging this sucker! :sunglasses:


requestPointerLock mousemove accuracy

For technical OS reasons, cross-OS reequestPointerLock implementation is kind of nasty. See https://github.com/glfw/glfw/issues/58.
The best way I know to do it is to force the cursor position to the center when you click in, and then on mousemove compute the delta from that while resetting back to the center.
Currently it'sq jumpy on the first mousemove because the delta is computed from the x/y of when we clicked in, not the center, resulting in a wild jump for the first event emit.
Probably the way to fix this is to handle all of this cleanly at the GLFW layer with the appropriate positioning hacks every other GLFW user is doing 🤔.

Fixed with https://github.com/webmixedreality/exokit/commit/2ecc04ff87d66aeccc701f0bddb208aac4bd6348.


[MINOR][SQL] Remove an unnecessary parameter of the PartitionedFileUtil.splitFiles

What changes were proposed in this pull request?
Remove an unnecessary parameter of the PartitionedFileUtil.splitFiles
Why are the changes needed?
Make code clearer.
Does this PR introduce any user-facing change?
'No'
How was this patch tested?
Pass GitHub Actions

Can one of the admins verify this patch?

Seems OK. There's no reason to expect external code would call this method right?

Although this is not a public api, it is still used by third-party projects based on Spark, for example:

NVIDIA/spark-rapids

https://github.com/NVIDIA/spark-rapids/blob/fb86a1a8042f241b31d29f2e48ef73820be734d7/sql-plugin/src/main/scala/org/apache/spark/sql/rapids/GpuFileSourceScanExec.scala#L479-L485
-gluten
https://github.com/oap-project/gluten/blob/2e0f16bbdbba4edd70846123147e24d0b90ce833/jvm/src/main/scala/io/glutenproject/utils/InputPartitionsUtil.scala#L43-L51

OK let's leave it if there's any doubt - just not worth messing with libraries that use even non-public APIs


[Bug] Kitsu anime tracking not working

Device information

Tachiyomi version: Latest stable and preview version
Android version: 10
Device: Oneplus 5T

The kitsu anime tracking only shows the manga's and not the anime.
Checked it with myanimelist but that one does work, but it's not the site I use to keep my library updated.
Would be awesome if it can be fixed.

Keep up the great work!

forgot to close. was fixed with https://github.com/jmir1/aniyomi/commit/9e2db50b77fdd99578eddc55d07cc343bacb049b.


ygilquin-media-grid integration

 All committers have signed the CLA.

Give up with this pull request, and reissue one with ygilquin-media-grid-clean branch


missing requirements.txt

A common practice for managing dependencies in python projects is to declare them in a requirements.txt file.

I've added the requirements.txt file. Thank you.


Not able to connect to spark deployed in yarn client mode

OS - RHEL 7.3
R version 3.4.1
spark_version <- "1.6.2"
sc<-spark_connect(master="yarn-client",version = "1.6.2", config=config )
I'm trying to create a spark connection but i get an error as shown below

I have tried passing config list, have verified my services are running and spark is deployed in yarn client mode.

We have the same issue on RHEL 7.2, R version 3.4.3, spark 2.2.0 with this call
library(sparklyr)
conf <- spark_config()
conf$spark.yarn.keytab <- "my.keytab"
conf$spark.yarn.principal <- "user@myserver"
sc <- spark_connect(master = "yarn-client", config = conf)

extract from logs
18/05/02 14:42:08 INFO sparklyr: Session (89997) is starting under <IP_ADDRESS> port 8880
18/05/02 14:42:08 INFO sparklyr: Session (89997) found port 8880 is available
18/05/02 14:42:08 INFO sparklyr: Gateway (89997) is waiting for sparklyr client to connect to port 8880
18/05/02 14:43:08 INFO sparklyr: Gateway (89997) is terminating backend since no client has connected after 60 seconds

If we had this to the conf
conf$`sparklyr.shell.deploy-mode` <- "client"
sc <- spark_connect(master = "yarn-client", config = conf)

this is working
extract from logs
18/05/02 14:55:44 INFO sparklyr: Session (34920) is starting under <IP_ADDRESS> port 8880
18/05/02 14:55:44 INFO sparklyr: Session (34920) found port 8880 is available
18/05/02 14:55:44 INFO sparklyr: Gateway (34920) is waiting for sparklyr client to connect to port 8880
18/05/02 14:55:44 INFO sparklyr: Gateway (34920) accepted connection
18/05/02 14:55:44 INFO sparklyr: Gateway (34920) is waiting for sparklyr client to connect to port 8880
18/05/02 14:55:44 INFO sparklyr: Gateway (34920) received command 0
18/05/02 14:55:44 INFO sparklyr: Gateway (34920) found requested session matches current session
18/05/02 14:55:44 INFO sparklyr: Gateway (34920) is creating backend and allocating system resources
18/05/02 14:55:45 INFO sparklyr: Gateway (34920) created the backend
18/05/02 14:55:45 INFO sparklyr: Gateway (34920) is waiting for r process to end

We've seen that this option is useful for cluster mode, so we tried it for client. It solves the connection issue but we did not understand why and we do not know if we are supposed to set this config or if it is a bug.
Hope it could be understand.


Support all constructors

Features and fixes

Support for pattern matching on variants

// given worker.response TypeAnnotatedValue::Variant { Foo ..}

match worker.response {
   Foo(value) => value.id
   Bar(value) => value.id
}

Fixed nested pattern matching - recursively identify the patterns

// given worker.response TypeAnnotatedValue::Variant { Foo ..{ Option { Result }

match worker.response {
   Foo(some(ok(value)) => value.id
   Bar(none) => value.id
}

Support on wild card

match worker.response {
   some(_) => worker.response.id
   none => 'not found'
}

Support on alias

match worker.response {
  a @ ok(b @ _) => b
  c @ err(d @ ok(e)) => {p : c, q: d, r: e.id}
}

Introduction of TypeMismatch

// given worker.response is TypeAnnotatedValue::U64(1)

// Following will result in type-mismatch error for the first arm itself - where we tried to match 1 with `ok`
match worker.response {
   ok(_) => "success"
   err(_) => "failure"
}

Stricter pattern matching. Previously any value from worker.response could be considered as Option::Some. Now that we moved to TypeAnnotatedValue which clearly has Some and None types for optional values. So we can pattern match strictly, otherwise we get a TypeMismatch error.

Disallowed random constructions. Removed Expr::Constructor0 to being explicit. That while we can pattern match on any variant, users cannot construct random constructors.

// Disallowed
match worker.response {
   some(_) => Foo(1)
   none => 'not found'
}

Expr cannot evaluate Foo(1) because it simply doesn't know what Foo is.

Expr::Result and Expr::Option (and removed Expr::Constructor0)

Tests in text module (for read and write) and evaluator module. The ones PR reviewers might be interested in is evaluator, to see the outcome of this PR

Cleanups that are as follows:

Removed higher order functions to evaluate if-else expressions
Separate module for if-else, to be consistent with other patterns
Removed the complex structure InternalExprResult (which was holding a function insider, on what to do in the next loop). Works well only in Scala!
Renaming. A pattern match should consist of match_expression and a collection of arms and LHS of arm is arm_pattern and rhs of arm is arm_body, following consistent naming around pattern matching expressions in the wild.

There can be many things where we could optimize, I do have an eye on these things, but I think time to take a step back and progress with what we have now, and optimize it with specific tickets in place.

@justcoon the display shouldn't fail as such for logical reasons. The std.io fails are mainly panic. I should be using only display instance everywhere. Merging this now.


Add standalone version

Adds a standalone version with its own local databases. Enabling standalone mode removes the website's dependencies on backend microservices. See the README for information on how to run the app standalone.
Main changes:

Add a Standalone folder that contains new all the code needed to enable the standalone version of the app
Minor changes to Startup.cs to configure services, middleware, and seed databases for the standalone version
Add App Insights to React frontend. Needed to change from BrowserRouter to Router with history passed in so App Insights and the router can both access a shared history object.
Stores product info in SQL Server, cart in MongoDB
The app should work exactly the same as it did before if standalone mode is not enabled

Hello,
We were adding your changes on complete deployment version and all is working except app Insights inside Reactjs,
Same app Insights implementation needs work with 2 websites versions (Standalone, Complete version).
That's why we need to send instrumentation key (app Insights) env variable from helm to our frontend (same way in all 2 cases).

Preparing helm scripts to support this new variable. Adding in Deploy folder / web / configmap the new instrumentationKey data variable. Add variable specification in values.yaml

dotnet application receives that variable and it has a controller containing all settings, this new variable needs to be here and sended to reactjs application. The appSettings files are OK, they are prepared but settings model is not we need to add the new key.

Reactjs, when we load all settings (loadsettings method) we need to add in ConfigService then in app.js we need to change window.appInsightsInstrumentationKey by the new instrumentation key retrieved.

you can see an example of this viewing how to we send ApiUrl variable.
regards,


Issue deploying to Netlify

I am trying to get a basic configuration going, but when I try to deploy to Netlify, it fails during the vite build:
7:39:24 PM: $ yarn build
7:39:24 PM: yarn run v1.13.0
7:39:24 PM: $ vite build
7:39:25 PM: failed to load config from /opt/build/repo/vite.config.js
7:39:25 PM: error during build:
7:39:25 PM: Error: You gave us a visitor for the node type StaticBlock but it's not a valid type
    at verify (/opt/build/repo/node_modules/@babel/traverse/lib/visitors.js:114:13)
7:39:25 PM:     at explode (/opt/build/repo/node_modules/@babel/traverse/lib/visitors.js:36:3)
7:39:25 PM:     at Object.merge (/opt/build/repo/node_modules/@babel/traverse/lib/visitors.js:149:5)
7:39:25 PM:     at Object.<anonymous> (/opt/build/repo/node_modules/@babel/helper-replace-supers/lib/index.js:68:44)
7:39:25 PM:     at Module._compile (node:internal/modules/cjs/loader:1101:14)
7:39:25 PM:     at Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
7:39:25 PM:     at Object.require.extensions.<computed> [as .js] (/opt/build/repo/node_modules/vite/dist/node/chunks/dep-e0fe87f8.js:68716:13)
7:39:25 PM:     at Module.load (node:internal/modules/cjs/loader:981:32)
7:39:25 PM:     at Function.Module._load (node:internal/modules/cjs/loader:822:12)
7:39:25 PM:     at Module.require (node:internal/modules/cjs/loader:1005:19)
7:39:26 PM: error Command failed with exit code 1.

I only use babel for my tests, so they shouldn't affect anything, but even removing the configuration still results in this error, so I am not even sure it's that at fault. Here the rest of my code:
Reload Prompt

<template>

        App ready to work offline

        New content available, click on reload button to update.

    <button
      v-if="needRefresh"
      @click="updateServiceWorker()"
    >
      Reload
    </button>
    <button @click="close">
      Close
    </button>

</template>

Vite Config
import path from 'path';
import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';
import vueI18n from '@intlify/vite-plugin-vue-i18n';
import { VitePWA } from 'vite-plugin-pwa';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    vue(),
    vueI18n({
      include: path.resolve(__dirname, './src/locales/**'),
    }),
    VitePWA({
      includeAssets: ['favicon.ico', 'robots.txt', 'apple-icon-180.png'],
      manifest: {
        short_name: 'Short Name',
        name: 'Name',
        icons: [
          {
            src: 'manifest-icon-192.png',
            sizes: '192x192',
            type: 'image/png',
            purpose: 'maskable any',
          },
          {
            src: 'manifest-icon-512.png',
            sizes: '512x512',
            type: 'image/png',
            purpose: 'maskable any',
          },
        ],
        start_url: '/dashboard',
        background_color: '#FFFFFF',
        display: 'standalone',
        scope: '/',
        theme_color: '#FFFFFF',
        description: 'Description',
      },
    }),
  ],
  server: {
    port: 8080,
  },
  build: {
    sourcemap: true,
  },
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
});

Any idea about this @antfu? 😢

@doutatsu babel is there, you can try rm -rf ./node_modules && rm yarn.lock && yarn

I was absolutely sure that I have tried that already - but as I was trying again, it did go through without issues. My bad, that was a dumb mistake

Unfortunately, even though it seems to be building the app, the service worker is not working - even after I followed the Vue 3 example...

I find the instructions a bit unclear, so I am probably missing something. I've followed the site documentation, but when I started looking into the vue example repo itself - there is some setup that is not mentioned in the documentation itself... for example, do I need to have this file in my repo https://github.com/antfu/vite-plugin-pwa/blob/main/examples/vue-router/src/claims-sw.ts? Am I missing something else? It's quite hard to tell to be honest

@doutatsu you need to call registerSW from virtual:pwa-register or if using vue, useRegisterSW from virtual:pwa-register/vue. If you don't call registerSW or useRegisterSW the sw will not be registered.

the example projects are condensed to allow test each framework with the same codebase using different strategies and behavior (registerType): if you use generateSW strategy you don't need any of the sw.

 I have to hard refresh on desktop and it requires opening and closing chrome on android several times as well to get it to load properly again. After this, the "new content has loaded" dialog pops and is confusing because it doesn't reload after you've already gone through the process I described.
In some cases, if I am using the site after a deploy, I will see the new content dialog pop and I can click reload and the client reloads fine.

On my side - I did manage to get it working and service worker seems to be working as expected. Not sure what it was in the end - but seems to be the combination of the correct Netlify configuration and properly calling registerSW, but I tried a lot of things, so not sure what exactly got it working for me


Is there a quick way to add new file type for pre-filtering?

This plugin indeed is awesome. I am new to these terminal stuff, so I am still struggling here.
The problem I have is that I have some graphql schema files in my project, but this type is not available for searching with pre-filtering.
I want to add this type so that I can use the feature. How can I do that or maybe it is impossible right now?

Hi, thanks for the kind words. It's a good question. The type list comes directly from rg (the extension queries Ripgrep with --type-list to create the dialog you're referring to).
I thought this list was a fixed set, but it turns out it's not so there's hope :) I just learned that:

you can call --type-add to add a new spec (e.g. graphql)
while that flag is not persistent, you can set it from a configuration file

Since the extension is definitely more targeted towards power users like yourself, and I can't ever support every type spec (rg already tried to do something like this and provided this solution), I'd recommend changing your rg configuration to add that type spec. It should just work as the extension simply invokes rg just like you yourself would in the terminal.
Since you said you're new to terminal stuff, let me give some more pointers as some of this might not be obvious (forgive me if you already know this stuff):

man rg shows all the documentation for rg including everything I just learned
it gives this example regarding configuration files: RIPGREP_CONFIG_PATH=wherever/.ripgreprc rg foo
so you need to ensure your environment contains RIPGREP_CONFIG_PATH and have it set to e.g. ~/.ripgreprc, which should then contain the configuration data.
this file should then contain the required incantation to add the graphql extension to rg
try this in the terminal first, before trying it in the extension. If it works, try it in the extension. If it fails, it's because VS Code happens to not have the same environment as your terminal (which depends on how you  start VS Code). In that case see this StackOverflow post for instructions on how to set environment variables for the VS Code terminal.

Hope this helps, good luck!

Thank you! I finally make it work.
As a non-native speaker, these documentations and commands are really overwhelming.
I guess I need to take times to learn more shell commands to be better with terminal stuff.
This journey is kind of frustrating but helpful in the long run, or I hope so.
The given pointers are really helpful. Hope you have a nice day!

For what it's worth you seem to be doing great on both English as well as terminal stuff so keep it up! I know dealing with the terminal can be a pain, but diving in and learning lots of things about it will make you far more productive if that's what you aspire :)


Support on-premise overleaf instances

Previously, all requests are hardcoded to go through to www.overleaf.com - this PR parameterises it in the Api class instead.

Looks good, thanks!


Chart becomes very slow when rendering large volume of data

Describe the bug
Importing a large amount of data into ECharts significantly slows down the application, it even unresponsive to any events. I'm using React Native SVG for chart rendering.
Expected behavior
The chart becomes significantly slow specifically when loading a large volume of data. How to overcome this issue ?
Screenshots

Smartphone (please complete the following information):

IOS simulator iphone 12 mini

There is too much views on your rendering tree.

Is there any possible way to render large volume of data ?
We have planned to use this package for our application despite the presence of this issue; however, everything else works perfectly fine.

Page the chart data or make a approximation to use lowest number of data possible.
Any chart library can become slow as the data grows too big.
Think the charts as something like Google Maps, you can't plot the whole city so as we zoom through the map new details should appear, as we zoom out the datails fade away but we can see the whole.

Thanks for the insight!


Disable exponential backoff

No reason to have exponential backoff here because there's only one instance of the scraper running, and it delays updating after an error is fixed.

Fixed.


fix ansible-lint issues with changed_when, others

Ansible lint now requires the use of changed_when: with commands
even in some cases where the command has a when condition.
Signed-off-by: Rich Megginson<EMAIL_ADDRESS>

[citest]