Typescript: Habilitar Ir a la implementación en los editores de mecanografiado

Entonces, desea que esta funcionalidad salte al .js si está disponible, siempre que la definición sea ambiental, ¿correcto?

@RyanCavanaugh @mousetraps @ bowdenk7

Entonces, desea que esta funcionalidad salte al .js correspondiente si está disponible, siempre que la definición sea ambiental, ¿correcto?
Sí, este es un escenario que sería muy útil para la productividad. Esto solo sería muy valioso. Creo que el autor de Atom-TypeScript cree que más ganchos en el compilador de TypeScript le facilitarían la implementación. No tengo claro si esta información sobre los números de línea de implementación de js es información que el compilador de mecanografiado normalmente conocería internamente.

Además, otro escenario sería permitir un salto a la definición del archivo .ts original mecanografiado en la biblioteca que utiliza la aplicación. Me imagino que esta información está disponible precompilada en archivos d.ts y .js. Ahora tenemos conjuntos completos de bibliotecas que se escriben en archivos .ts como fuente que genera la sintaxis de ES5 js. Sería bueno lograr la capacidad de saltar a la definición de implementación de mecanografiado original en los archivos .ts.

Soy consciente de que esto está pidiendo aún más que salte a la implementación del archivo .ts en la biblioteca requerida, ya que podría necesitar el uso del mapa fuente o la distribución de la fuente / enlace a la fuente ts original. Me parecería que el compilador de mecanografiado que genera la biblioteca inicial de funciones y clases conocería las líneas en las que se encuentra la implementación y podría conservar los números de línea cuando la biblioteca se distribuya de alguna manera para que el compilador de mecanografiado de la aplicación que usa la clase podría saber a qué línea saltar en la biblioteca.

¿Está disponible esta información en el número de línea de la función / clase de implementación en los mapas de origen? ¿Existen otras fuentes de esta información?

Dado que vamos a utilizar la bandera --allowJS , el servicio de idioma debería poder trabajar con los archivos JS.

No sé cómo los archivos .d.ts y los archivos .js funcionan juntos actualmente en ese sentido. @sheetalkamat probablemente (definitivamente) sepa más sobre esto que yo.

Reapertura, porque todavía no se admite el acceso a archivos js

¿Alguna actualización en este? El estado actual del mecanografiado es que no se puede saltar a la implementación del código en muchas bibliotecas importantes.

Este problema se ha movido / cerrado / engañado / deducido varias veces y corregir este error podría suponer un gran aumento de productividad.

https://github.com/ubershmekel/vscode-ts-goto-source tiene un proyecto que reproduce el problema. Como se explica en https://github.com/Microsoft/vscode/issues/26325 y se hace referencia en https://github.com/Microsoft/vscode/issues/10806 y https://github.com/Microsoft/vscode/issues / 18321

Tenga en cuenta que tuve que usar "typescript.disableAutomaticTypeAcquisition": true desde un punto para usar el javascript "ir a la definición" porque parece que los archivos .d.ts toman el control si se encuentran.

@DanielRosenwasser ¿ Alguna actualización sobre esto? - Característica única más buscada para mí.

Esto es particularmente molesto si se trabaja en un monorepo escrito completamente en TypeScript. Varias veces cuando agregué un campo a un tipo o cambios más pequeños similares usé "ir a la definición", lo agregué y luego descubrí que faltaba nuevamente al darme cuenta de que lo agregué al archivo .d.ts y no al .ts real

@DanielRosenwasser ¿Está progresando? Realmente me encantaría esta característica

mismo problema. Quiere "Ir a la implementación" al código fuente, no xx.d.ts

Sí, varias veces al día edito por error el archivo de declaración después de usar cmd + clic y termino confundido cuando el código no se ejecuta correctamente. Especialmente porque src y dec son muy similares. Sería increíble si hubiera alguna forma de elegir si quiero ir a la fuente de declaración, o incluso mejor si VSCode descubriera esto, ya que ir a la fuente es siempre más preferible en mi humilde opinión (si está disponible).

ir a la fuente es siempre más preferible en mi humilde opinión (si está disponible)

Cuando la fuente está en TS. Si la fuente está en JS, hay una buena razón para ir a .d.ts

Cuando la fuente está en TS. Si la fuente está en JS, hay una buena razón para ir a .d.ts

¿Por qué? Puedo desplazarme para ver la definición de tipo. De todos modos, debería haber un comando separado para la definición de tipo frente a la implementación.

¿Hay alguna razón por la que esto aún esté pendiente? ¿Una solución, alternativa o algo así? Gracias por adelantado

Dado que el analizador de TypeScript a menudo genera los archivos d.ts a partir de los archivos de implementación .ts. ¿Podría preservarse esa asociación entre los archivos d.ts y .ts (quizás la salida con una opción de compilador de mecanografiado) para que los editores de Typecript pudieran llevar a los desarrolladores a una lista de las clases o funciones de implementación?

Tengo una rama de # 21930 que permite producir precisamente estos mapas fuente de archivos de declaración (y los tendré para revisión ya sea a pedido o una vez que # 21930 se haya fusionado), y estoy trabajando para agregar soporte en nuestro LS para seguir estos mapas. Queremos enviarlo en 2.8.

Así que sí, hemos estado trabajando en ello. Solo necesitaba muchos cambios internos. 😄

Espere actualizaciones sobre este problema para aliviar el dolor de encontrar implementaciones a través de carpetas expandidas manualmente en node_modules y ubique el archivo del módulo de entrada.

¿Existe alguna solución para esto?
Como tenemos un gran módulo para nuestras consultas de base de datos escrito en ts, sería muy bueno ver el código fuente real con un comando en lugar de buscar a través de node_modules.

@ derN3rd Hay vscode-search-node-modules extensión para navegar node_modules en el panel de comandos (y también tengo una bifurcación que siempre abre README vscode-open-node-modules )

Entiendo que está lejos de ser la experiencia perfecta para hacer clic en requerir / importar y abrir un archivo de código abierto, pero definitivamente es mejor que desplazarse node_modules

@ derN3rd enviaremos una bandera --declaratrionMap en 2.9 (que puede ser lanzada durante el próximo mes), y ya hemos habilitado ir a las definiciones en el TS original de la fuente sobre un .d.ts asociado usando ellos (que, si está enviando archivos de declaración en la carpeta de módulos de su nodo, puede obtener mucho de lo que desea). También estamos buscando saltar hacia / desde el JS asociado, siempre que los mapas de origen normales también estén activados.

@weswigham ¡ gracias por la rápida respuesta! Suena bien
¿Podría publicar una actualización aquí si la función está lista o lista para ser probada?

--declarationMap (y la redirección LS asociada) ha estado en nuestros nightlies desde justo después del lanzamiento 2.8. Lo único que aún no hemos hecho es el salto de archivos JS, ya que puede requerir cierta coordinación adicional del editor.

¿Alguna noticia para eso en 3.0-rc?

El mismo problema con los archivos .css y .json . Vaya a Definición y me lleve al archivo .d.ts .

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'

Ir a Definición en ./App.css me lleva a

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

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

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

VS Code ahora se envía con TypeScript 3.0.3. ¿Alguna novedad sobre este asunto?

Funciona para mí (mapas de declaración generados con TS 2.9.2, ejecutando VSCode 1.27.0). Navegar desde un consumidor de API (implementado en JS) _Go to Definition_ me lleva a la implementación en el archivo .ts.

@robsman _Go to Definition_ debería llevarlo al código js compilado, mientras que _Go to Type Definition_ debería llevarlo al archivo .d.ts.

¿Cómo usa / incluye su módulo compilado para abrir los archivos fuente?

Ese problema todavía existe para mí en VSCode 1.27.0, ya que ambas funciones me llevan al archivo .d.ts

EDITAR: Creo que entendí mal tu comentario. ¿Te lleva al código real? Si es así, ¿está utilizando un monorepo o su código compilado se envía en un módulo npm propio? ¿Envían los archivos fuente con su código compilado?

@ derN3rd volvió a probar, tanto _Ir a Definición_ como _Ir a Definición de tipo_, así como _Definición de Peek_ me llevan al código real en el archivo _.ts_.

La declaración y la implementación de la API se encuentran en un módulo separado al que el paquete de llamada se refiere como una dependencia _git + ssh ..._.

@robsman Creo que Go to Definition debería referirme a la fuente de "esta" clase o función en el archivo fuente js (si es javascript) dentro de node_modules no .d.ts . Como funciona en Sublime Text 3, quiero decir. De todos modos, no entiendo para qué VSCode esta función en el estado actual

Hope puede priorizar este tema, es realmente un gran dolor, por tantos comentarios y temas relacionados.

Por favor, agrégueme a la larga lista de personas que intentan usar el comando y hacer clic para navegar por el código. No tengo TS en mi proyecto y el paquete npm al que estoy navegando no usa TS, sin embargo, hacer clic en command-click en require ('co-body') me lleva a una definición de TS generada internamente. Soy usuario de IntelliJ desde hace mucho tiempo y aún así, debido a esto, recurro a IntelliJ.

es una solicitud larga

Me gusta mucho VS Code y acabo de comenzar un nuevo proyecto Node y decidí usar TypeScript por primera vez. Hasta ahora todo bien, pero este problema ha sido un punto de dolor. Al trabajar en código abierto, la capacidad de hacer clic en el código fuente real en dependencias es vital para el flujo de trabajo. Estoy trabajando en archivos fuente de TypeScript y usando módulos JS NPM con módulos @types/xxx asociados que no tienen documentación asociada. IntelliSense con TypeScript es excelente, pero no siempre proporciona suficiente información. Como mínimo, sería bueno poder hacer clic directamente en la fuente del módulo desde la declaración import . Creo que en algunas bibliotecas que funcionan, y en otras, por ejemplo, Passport, no puedo pasar de los stubs adjuntos de TypeScript en el módulo @types .

Esto debe etiquetarse como _Bug_, no _Suggestion_.

La falta de navegación por el código realmente arruina la experiencia de VSCode para los desarrolladores de JavaScript.

perdón por enviar spam al hilo pero search-node-modules 😬 por ahora

WebStorm tiene el mismo comportamiento: StackOverflow , BugTracker

• VSCode tiene acciones "Ir a definición" e "Ir a definición de tipo"

• WebStorm tiene las acciones "Ir a la declaración" y "Ir a la declaración de tipo"

Pero cuando se usa TypeScript, ambos IDE hacen lo mismo: ¡vaya siempre a la definición de tipo!

"Ir a la definición" y "Ir a la definición de tipo", cuando se usa en bibliotecas node_modules/ , ambos me llevan a los archivos .d.ts . Estoy en el último VS Code al momento de escribir (1.34.0).

Por ejemplo: paquete npm @angular/[email protected] , cuando importo TestBed de @angular/core/testing y trato de ver la definición de TestBed.createComponent , obtengo dos cosas diferentes:

• "Ir a la definición" -> node_modules/@angular/core/testing/src/test_bed_common.d.ts línea 117
• "Ir a Definición de tipo" -> node_modules/@angular/core/testing/src/component_fixture.d.ts línea 14

Esto básicamente significa que el código fuente de Angular está oculto para mí en VS Code 😞 No estoy seguro de si eso es un síntoma de cómo está escrita la biblioteca Angular, o cómo TypeScript / VS Code encuentra implementaciones de fuente.

Todo lo que sé es que solo puedo usar de manera confiable "Ir a la definición" y "Ir a la definición de tipo" en mi propio código, en cuyo caso me llevan directamente a la fuente; Nunca me muestran un archivo .d.ts para mi propio código.

Tenemos que buscar manualmente los códigos fuente por ahora: /

Aw, acabo de descubrir que de alguna manera Intellij IDEA hace que esta función funcione muy bien, incluso si estoy en el mismo proyecto, usando Typescript 3.0.1

Pensé que debería aumentarse la prioridad de este tema.

Tenemos que ordenar + , para abrir la configuración del espacio de trabajo -> desmarcar Use Ignore Files -> eliminar Search: Exclude: **/node_modules , y buscar manualmente los códigos fuente.

¡COTIDIANO!

Por eso, flow sigue siendo útil.

¿Podría alguien del equipo de mecanografiado sugerir en qué parte del código se puede solucionar esto?

Lo curioso es que si algún paquete no tiene tipos disponibles, "Ir a definición de tipo" funciona mejor para él. Significa que no usar mecanografía es mejor si te gustan las funciones "Ir a" 😄

Aquí está el screencast que muestra que puedo ir a la definición de device paquetes que no tienen mecanografía, pero compression me lleva a un archivo de mecanografía aleatoria:

https://giphy.com/gifs/j3VCp0LVKr5LsMUh11

@RyanCavanaugh Debo estar de acuerdo con otras personas, esto debe etiquetarse como error, no como sugerencia.

en mi caso, si tengo algo como esto definido en mi propio código

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

si la T proviene de un módulo npm, cuando trato de ir a la definición, me mostrará 2 definiciones. Mi propio código y la definición de escritura. Si voy a la definición de tipo, va directamente al archivo de definición.
En el primer caso, debería ir directamente a la definición.
Para solucionar esto, cambié el editor -> goto location: multiple to goto lugar de peek

Necesito esta característica. ¿Cómo puedo ayudar con su implementación?

+1 para esto por favor!

desde 2015 y sin soluciones :(

El OP estaba preguntando si podíamos ir a los archivos .ts cuando encontramos archivos .d.ts , si envía los archivos .ts con los archivos .d.ts y la declaración mapas generados por --declarationMaps , ese es nuestro comportamiento actual (así que está bastante hecho). La _second_ solicitud en este hilo, que es lo que ahora rastreamos aquí, es una opción para ir al archivo de salida .js (que podría ser útil si, por ejemplo, las fuentes .ts no son ' t enviado). En cuanto a la implementación, eso es solo una cuestión de combinar los mapas fuente de declaración y los mapas fuente javascript que ya emitimos, sin embargo, lo que no hemos decidido es cómo debería aparecer dicha característica. Go to implementation en el código ts ya tiene un significado útil para la mayoría del código (que es ir a la definición, pero prefiero las declaraciones de implementación / valor) ... ¿lo modificamos de alguna manera (por ejemplo, si resolvemos una declaración , intente resolverlo en un archivo js en su lugar), o agregamos un nuevo punto final? Si es más tarde, tenemos que hablar sobre cómo queremos sacarlo a la luz con el equipo de vscode.

@DanielRosenwasser honestamente, lo que realmente necesitamos aquí es solo una descripción más detallada de exactamente cómo queremos exponer algo como esto: las herramientas para hacerlo ya están en su lugar.

Los codificadores del equipo de vscode pueden proponer ideas sobre cómo se debe implementar, por ejemplo, Go to js implementation o algo así, un primer buen paso sería crear un ticket en el rastreador de problemas de vscode y hacer una referencia cruzada de estos tickets para que la comunicación pueda empezar.

Tengo entendido que aquí hay varios problemas relacionados. (1) es el más grande, pero también debemos tener en cuenta los demás:
1) No hay una manera fácil de navegar a la implementación de JS o TS de un tipo de TS si ese tipo se declara en un paquete DefinitelyTyped. (u otros casos en los que .d.ts no está ubicado con la implementación)
2) Ir a definición de tipo no funciona cuando la selección es en sí misma un tipo. Obtendrá el error "No se encontró ninguna definición de tipo".
3) Ir a definición en un identificador que no es de tipo se comporta de manera incoherente. A veces, navegará hasta la implementación, a veces no. En teoría, esto es lo mismo que (1), pero también es posible resolver (1) dejando esta inconsistencia en su lugar.

Creo que sería más sencillo para los usuarios resolver los tres problemas _sin_ agregar una tercera opción de menú "Ir a". En cambio, mi sugerencia sería retener solo dos elementos del menú pero hacer que se comporten de manera más consistente:

• Ir a la definición siempre debe navegar a la implementación , independientemente de si se trata de un código local, un paquete node_modules con archivos .d.ts integrados o una definición DefinitelyTyped separada del paquete JS.
• Ir a definición de tipo siempre debe navegar hasta la declaración de TS , independientemente de si la selección es un identificador de tipo o no.

¿Existen otros casos de uso comunes de TS que requieran una tercera opción?

Por cierto, creo que podríamos cambiar el nombre de "Ir a la definición" a "Ir a la implementación" si quisiéramos aclarar la distinción, pero en mi humilde opinión, esto parece un cambio opcional. La consistencia (independientemente del nombre) es el bit de orden superior.

No hay una manera fácil de navegar a la implementación de JS o TS de un tipo de TS si ese tipo se declara en un paquete DefinitelyTyped. (u otros casos en los que .d.ts no está ubicado con la implementación)

_Técnicamente_ si quisieras girar a mano algunos mapas de código fuente para ir con un paquete DT, ya podría funcionar. Pero definitivamente no hay una solución automatizada aquí. Cualquier solución que tengamos se basa en mejorar los escenarios que involucran la salida del compilador de TS, en esos son los únicos momentos en los que podemos actualizar los metadatos adicionales necesarios para realizar las asociaciones correctas entre archivos. Algunos paquetes admiten esto hoy, creo. Estaba usando el sdk azure js el otro día y depurando algunas cosas, y me sorprendió gratamente cuando fui a algunas definiciones y descubrí que estaban en la fuente original. Así que sí, funciona con fuentes TS que tienen una salida actualizada --declarationMaps incluida.

Ir a definición de tipo no funciona cuando la selección es en sí misma un tipo. Obtendrá el error "No se encontró ninguna definición de tipo".

Creo que todos deberían abrir una nueva edición sobre ese tema. Eso es solo un error de ejecución / error, en mi opinión. Como mínimo, el error podría mejorarse: algo como "la selección es solo un tipo y, por lo tanto, no tiene una definición de tipo asociada con su valor".

Ir a definición en un identificador que no es de tipo se comporta de manera incoherente. A veces, navegará hasta la implementación, a veces no. En teoría, esto es lo mismo que (1), pero también es posible resolver (1) dejando esta inconsistencia en su lugar.

Va a la _first_ definición, donde primero es bastante arbitrario, y se basa en cosas como el orden en que se cargaron los archivos. La ventana peek es ciertamente más útil, ya que muestra todos los sitios de definición. Las "implementaciones" no entran en juego.

Como usuario, estaré satisfecho si funcionó así:

Ctrl + clic en un símbolo (principalmente uso solo esto para navegar por el código) lleva actualmente a una implementación (si está dentro del paquete que se está editando en VS Code) oa la declaración (si es un paquete de las dependencias) . El primero no requiere consideración. El segundo, cuando va a la declaración, me gustaría presionar Ctrl + Click en la declaración y me lleva a la implementación, si puede localizarla, descargarla y abrirla por mí. De lo contrario, muestra un mensaje sobre el problema que impidió que se encontraran / abrieran las fuentes. Si funcionara así, sería genial.

Creo que existen los siguientes escenarios para localizar el código fuente original:

1. Un paquete está escrito en mecanografiado y código fuente original en un repositorio externo y
   a) la distribución incluye archivos d.ts y js O
   b) la distribución incluye archivos d.ts , js y ts
2. Un paquete está escrito en mecanografiado y código fuente original en el repositorio actual (caso de repositorio mono) y
   a) la distribución incluye archivos d.ts y js
3. Un paquete está escrito en javascript y código fuente original en un repositorio externo y
   a) la distribución incluye sus propios archivos d.ts y js O
   a) la distribución incluye solo archivos js y se utilizan definiciones externas @types
4. Un paquete está escrito en javascript y código fuente original en el repositorio actual (caso de repositorio mono) y
   a) la distribución incluye sus propios archivos d.ts y js

1b): se usa con poca frecuencia, y no me gusta este enfoque, ya que recursos como bundlephobia y las tendencias npm informarán tamaños de paquetes enormes, que en realidad no son enormes en tiempo de ejecución, pero la gente juzga el tamaño en función de estos recursos. Por lo tanto, confiar en que los mantenedores incluyan archivos ts con la distribución no es una buena idea, pero ciertamente si se incluyen archivos ts , el caso está resuelto.

1a) - (¿más?) Caso frecuente. El paquete debe declarar de alguna manera (¿a través de package.json o mapas de origen?) Dónde se ubicaron las fuentes originales cuando se compilaron (como microsoft pdb declaran los archivos de símbolos) O de dónde se pueden descargar, por ejemplo, git + revisión + sendero. El código VS navegaría al archivo local o git fetch al caché local y lo abriría en la navegación desde la declaración hasta la implementación

2a): si es posible detectar el caso de un repositorio mono automáticamente (usando algunas heurísticas), la navegación original Ctrl + Click podría abrir la implementación directamente. Si es imposible, recurrir a 1a) es suficientemente bueno

Me importa menos 3, pero sería bueno si 3a) pudiera abrir la implementación de JS en la segunda navegación Ctrl + Click. En el caso de 3b), el paquete @types debe declarar qué paquetes JS anota, por lo que el código VS podría tener esta información para navegar a la implementación de JS en el paquete externo.

Me importa aún menos el 4, pero podría tener el mismo comportamiento que 2a) - el respaldo para 4a) es 3a)

Espero eso ayude.

1a) - (¿más?) Caso frecuente.

Sí, eso es lo que estoy diciendo que ahora tenemos todas las herramientas para brindar soporte. Podemos combinar archivos .js.map y .d.ts.map para producir un mapeo desde .d.ts a .js (sin el .ts intermedio). Pero, hm. Realmente, ¿preferiría ir al archivo de declaración y luego interactuar nuevamente para ir a los js asociados? ¿No querrías saltar directamente a las js?

"¿De verdad, preferirías ir al archivo de declaración y luego interactuar de nuevo para ir al js asociado? ¿No querrías saltar directamente al js?"

En el caso de 1a), el salto doble o el salto simple están bien para mí. Aunque el salto simple puede considerarse "más eficiente", el salto doble tiene la ventaja de "recordar" al usuario que el segundo salto es un salto a la caja negra desde el punto de vista del "consumo de la biblioteca" (es decir, un recordatorio de que la fuente el archivo al que se navega no forma parte del proyecto actual). Quizás este comportamiento podría configurarse.

En el caso de 3a), 3b) o 4, ciertamente quiero doble salto. Primero quiero ver las declaraciones y solo después de esto (en casos muy raros, como la depuración) la implementación. Saltar directamente a JS omitiendo la declaración TS elimina todos los beneficios de las declaraciones. Entonces, definitivamente quiero ver la declaración de TS primero.

(combinando respuestas a @weswigham y @avkonst de múltiples publicaciones)

Va a la primera definición, donde primero es bastante arbitrario, y se basa en cosas como el orden en que se cargaron los archivos.

En el caso más común en el que desea ir a la implementación de un símbolo importado en particular, ¿por qué habría múltiples definiciones? ¿Es esta una situación común?

producir un mapeo de .d.ts a .js (sin el .ts intermedio).

No estoy seguro de entender "sin el TS intermedio". ¿Quiere decir que incluso si la fuente .ts original está disponible, VSCode navegará al .js transpilado? Eso parece una mala idea. Si la fuente original está disponible, VSCode debería navegar allí, tal como lo haría cuando el depurador ingresa al código transpilado que tiene un mapa fuente. Dicho esto, si el autor del paquete era malvado o vago y no incluyó la fuente TS original en su distribución npm, entonces parece razonable que VSCode recurra al JS transpilado y tal vez muestre un mensaje de advertencia que explique por qué el usuario está viendo código tan extraño e ilegible y para animar a los usuarios a regañar al autor del paquete para que incluya la fuente original en su paquete.

Realmente, ¿preferiría ir al archivo de declaración y luego interactuar nuevamente para ir a los js asociados? ¿No querrías saltar directamente a las js?

No creo que dos pasos agreguen valor. Creo que es mucho mejor tener una experiencia de usuario distinta y coherente: use "Ir a definición de tipo" para navegar a la definición de tipo y use Ir a definición (o Ir a implementación, como decidamos llamarlo) para ir al original código fuente o, según lo anterior, al JS transpilado si la fuente original no está disponible.

En mi humilde opinión, es mucho más confuso tener un comportamiento diferente dependiendo de si el símbolo seleccionado está definido en su propio código o en node_modules. No debería importar. Si quiero ver el tipo, VSCode debería llevarme al tipo. Si quiero ver el código de implementación, VSCode debería llevarme allí. Esto es especialmente cierto porque, en las grandes organizaciones, lo que es "mi código" y lo que es "código de biblioteca" no siempre es una línea clara. Si alguien más refactorizó el código en un paquete interno compartido, no debería tener que cambiar la forma en que navego hasta ese código.

Primero quiero ver las declaraciones y solo después de esto (en casos muy raros, como la depuración) la implementación.

Parece que es más claro exigir al desarrollador que elija explícitamente (eligiendo un elemento de menú u otro) si desea ver una declaración de tipo o ver el código de implementación. Hacer que la navegación sea inconsistente dependiendo de dónde provenga el código parece innecesariamente confuso.

> Ir a definición de tipo no funciona cuando la selección es en sí misma un tipo.
Creo que todos deberían abrir una nueva edición sobre ese tema. Eso es solo un error de ejecución / error, en mi opinión.

Sí, esto definitivamente podría arreglarse primero. Lo incluí aquí porque si se adopta mi solución preferida ("Ir a la definición siempre navega a la implementación"), los usuarios se acostumbrarán a usar Ir a la definición de tipo siempre que quieran ver los .d.ts, por lo que Sería extraño si hacer esto en un tipo no actuara de manera consistente con la forma en que actúa para un identificador que no es de tipo.

"Va a la primera definición, donde primero es bastante arbitrario, y se basa en cosas como el orden en que se cargaron los archivos".

No he mencionado en mis respuestas que debería navegar a la primera definición. Dije en Ctrl + Click en un símbolo que debería ir primero a la definición (como funciona ahora) y solo en el Ctrl + Click posterior a la implementación.

"Parece que es más claro exigir al desarrollador que elija explícitamente (eligiendo un elemento de menú u otro) si desea ver una declaración de tipo o ver el código de implementación".

Los menús contextuales separados está bien y es una buena idea tenerlos. No son mutuamente excluyentes del comportamiento Ctrl + Clic.

Me pregunto por qué no se está trabajando todavía en este error crítico. Se está convirtiendo cada vez más en un dolor de cabeza a medida que aumenta la adopción de textos mecanografiados.

No quiero escuchar explicaciones técnicas, quiero saber por qué este problema ni siquiera se reconoce después de tanta descripción sobre diferentes usuarios.

@zjaml , ¿desea que vaya a archivos fuente de TypeScript o archivos fuente JavaScript? Se admiten archivos fuente de TypeScript. Son archivos fuente JavaScript para los que este problema aún está abierto.

Relacionado tangencialmente; Tengo un monorepo con un paquete común que se publica en npm. Debido a esta interfaz pública, los archivos dist son js + d.ts. Cuando estoy trabajando en el repositorio, VSCode siempre salta a d.ts en lugar de a la fuente. ¿Conoces una forma de evitar esto?

@ 0x80 Creo que este problema aún está abierto para el escenario que acaba de describir. La única forma en que creo que podría evitar esto es si el proyecto es de código abierto y lo compila a partir del código fuente mecanografiado. Luego, puede activar la marca --declarationMaps para el compilador de mecanografiado y los IDE que admiten los mapas de declaración irán a la fuente de mecanografiado en lugar de a los archivos d.ts.

Esto es realmente crucial. Quiero algo simple: CTLR + Haga clic y navegue hasta el archivo node_modules / library / source.js o source.ts. Proyecto de código abierto con 60 dependencias node_modules y ha vuelto a utilizar el bloc de notas con el explorador.

Cuando hice clic con el botón derecho en un componente, vi: "Ir a la definición" y "Ir a la definición de tipo". Pensé "¡Genial, esto ha sido bien diseñado, la solución a mi problema está aquí!". Luego hice clic en "Ir a la definición" y ... aterricé en la Definición de tipo.

Esto es realmente crucial. Quiero algo simple: CTLR + Haga clic y navegue hasta el archivo node_modules / library / source.js o source.ts. Proyecto de código abierto con 60 dependencias node_modules y ha vuelto a utilizar el bloc de notas con el explorador.

+1
Misma necesidad.

Con el debido respeto, el hecho de que esto no se implemente es increíble. Tan básico, relativamente fácil de
construir una función que le ahorraría a la gente toneladas de tiempo.

Con el debido respeto, el hecho de que esto no se implemente es increíble. Tan básico, relativamente fácil de
construir una función que le ahorraría a la gente toneladas de tiempo.

+1

Bueno, mientras tanto, cuando esta función aún no está disponible, ¿hay alguna solución mejor además de buscar todos los módulos de nodo? Realmente es un inconveniente ...
Por ejemplo, voy a la definición y me llevó a node_modules/@com.abc/sample/lib/core/internal/abc.d.ts cuando el que quiero está ubicado en node_modules/@com.abc/sample/src/core/internal/abc.ts

@ Felices

¿Hay alguna solución mejor además de buscar todos los módulos node_modules?

La solución actual AFAIK son mapas de declaración . Estos son mapas de origen que asignan archivos .d.ts al origen de TS correspondiente. Si puede convencer a las bibliotecas de las que depende para implementar mapas de declaración (que creo que efectivamente requiere publicar .d.ts dentro del paquete de la biblioteca en lugar de confiar en @types), entonces podrá saltar automáticamente desde su código de cliente al código fuente TS original (o incluso JS si se usa el compilador TS en JS?).

Lo que he estado haciendo es archivar gradualmente PR en mis dependencias más importantes (al menos las que están creadas en TS) para que agreguen mapas de declaración.

Obviamente, sería mejor si no fuera necesario cambiar la biblioteca.

Otra solución alternativa (si no es posible cambiar la biblioteca) funciona en el caso de que la biblioteca incluya .d.ts dentro del paquete pero no tenga mapas de declaración. En ese caso, usaré Ir a definición para llegar a la declaración de tipo, luego haré clic en el botón Explorador en VSCode para mostrar la barra lateral de la carpeta. Eso generalmente me acerca mucho a la carpeta src del paquete, por lo que en lugar de tener que buscar en todos los node_modules, puedo buscar en la carpeta correcta y abrir el archivo correcto. Esto depende de un nombre de archivo claro, etc. y no es una panacea.

Para ser 100% claro, me encantaría ver una mejor solución para las bibliotecas, especialmente. aquellos en los que .d.ts se crea por separado del paquete.

No estoy seguro si me lo he perdido, pero sería realmente útil para comprender lo que está sucediendo tener ejemplos mínimos reales de fuentes, declaraciones y mapas de declaraciones. Nunca he visto Ir a Definición, Ir a Definición de tipo o Ir a Implementaciones en realidad ir a otra cosa que no sea un archivo .d.ts para TS transpilado. Intenté hacer un ejemplo simple y no funciona; No puedo hacer que VS Code vaya a otra cosa que no sea el archivo .d.ts , aunque el .d.ts.map está al lado. También encontré a otra persona con el mismo problema que fue ignorada.

Es comprensible que admitir mecanografía externa como @types sería difícil, pero ¿qué dice que ni siquiera el "camino feliz" puede funcionar?

Hay muchas bibliotecas que generan archivos de declaración pero no mapas de declaración, y no está claro cuál sería el argumento para habilitarlos. Esta opción se ha agregado sin una explicación clara, al menos una que podría encontrar.

Sí, confirmo que los mapas de declaración no resuelven el problema. Mi proyecto tiene mapas de declaración pero vscode no navega más allá de los archivos .d.ts.

Seguro que sería genial si esto sucediera.

si hay un "elefante en la sala" de problemas para los desarrolladores de ms vscode, esto es todo.

¿Alguna actualización en este?
Decidí dar un gran paso: pasar de JS a TS. Pensé - "¿qué estoy haciendo mal?" pero en realidad, es un comportamiento inesperado de VSCode

¿Alguna actualización en este?
Decidí dar un gran paso: pasar de JS a TS. Pensé - "¿qué estoy haciendo mal?" pero en realidad, es un comportamiento inesperado de VSCode

Era una larga historia desde que se planteó este comportamiento. Bueno, no pasa nada aquí. No hay plan hasta ahora.
Para mí, sigo usando vscode como una especie de editor tal como es, y los productos Intellij (IDEA) para mis productos de codificación, incluso a mí no me gusta tanto.

Abierto por 5 años, espero que se arregle en 2025

He creado pruebas fallidas en # 39426 pero no sé cómo implementarlas

Solo otro comentario miserable de ts dev pasando por el infierno todos los días para encontrar definiciones

Esto es una locura ... Pensé que solo era un novato de TS, pero ahora veo que el comportamiento que estoy obteniendo es en realidad "estándar". Muy frustrante, todos los demás IDE / lenguaje que he usado tienen esto implementado en el lanzamiento inicial ... :( Me encanta el código VS pero, honestamente, esto podría ser un factor decisivo

¿Alguien puede explicar por qué go to definition/implementation características en VSCode con extensiones de Python para, eh, el lenguaje Python funciona mejor (funciona al menos) que JS que tiene soluciones integradas nativas?

¿Entonces qué está pasando?
Estoy usando scss.d.ts para módulos css y no puedo saltar a scss.

Además, al crear .js simples y, en consecuencia, d.ts, no puedo saltar directamente a js

¿por qué no usar webstorm?
¡Puede resolver este problema!
mi versión 2020.1

¿por qué no usar webstorm?
¡Puede resolver este problema!
mi versión 2020.1

Porque no es una solución de código abierto y no es gratis

Por favor arregle esto.

Está absolutamente claro que este problema solo se puede solucionar si algún gerente de Microsoft se hace cargo, este problema tiene que ser administrado y coordinado, un gerente desarrolla un flujo de trabajo y asigna trabajo a los codificadores. ☝
Este problema debe enviarse a la dirección para que se haga cargo y ellos decidan cómo se implementará.
Entonces, si hay alguien competente de Microsoft, puede intentarlo. 😊