Definitelytyped: webpack-env.d.ts no se compila con node.d.ts

Creado en 9 feb. 2016 · 6Comentarios · Fuente: DefinitelyTyped/DefinitelyTyped

Antes de preguntar: Sí, busqué y encontré el número 6334, aunque esto no resuelve mi problema.

Estoy escribiendo una aplicación web que usa Webpack. Como resultado, necesito acceso a webpack-env.d.ts en la interfaz, pero también estoy interesado en usar el módulo url de Node (por url.parse ). Si necesito webpack-env.d.ts y node.d.ts en el mismo archivo de referencias, es previsible que se rompa porque Node redefine require . OIA, necesito acceso a node.d.ts 's url módulo y webpack de require definición.

Puedo solucionar esto usando const url: any = require('url') , aunque esto no es ideal y me gustaría tener mecanografía para este módulo. Otra opción sería dividir node.d.ts en sus módulos constituyentes y hacer que el maestro node.d.ts requiera cada módulo individual, aunque no estoy seguro de si esto rompería algo de las muchas personas que confían en esto. Archivo de declaración de TypeScript, y particularmente no quiero piratearlo localmente.

¿Alguna sugerencia?

Fuente

danpantry

👍3

Comentario más útil

pero ¿qué pasa si @types/node es una dependencia de otra dependencia (por ejemplo, fs-extra , jsdom , shelljs , tape )?
también terminó eliminando webpack-env y

if ((module as any).hot) {
...

😢

vyorkin en 4 dic. 2016

👍5

Todos 6 comentarios

Bueno, técnicamente todavía no está en el entorno de nodo y no es correcto incluir todo el archivo node.d.ts. Está utilizando un paquete npm que actúa de la misma forma que la "url" del nodo, pero en el entorno del navegador. Lo que puede hacer es extraer esos tipos de node.d.ts y tener una url.d.ts separada, como ya sugirió. Es posible que simplemente dividir node.d.ts en módulos más pequeños no se adapte a todas las necesidades, porque las firmas pueden ser diferentes debido a las diferencias del entorno (búferes frente a matrices) o implementaciones. Sugeriría una escritura independiente para este paquete "url".

use-strict en 10 feb. 2016

Me encontré con el mismo problema en el que uso incluir typings/index.ts en mi tsconfig.json para incluir todos los mecanografiados. Al agregar webpack-env.d.ts y node , el compilador mecanografiado obviamente se queja. ¿Hay alguna forma de evitar esto?

test_index.ts(1,28): error TS2339: Property 'context' does not exist on type 'NodeRequire'.

foklepoint en 13 ago. 2016

La forma en que lo "resolví" fue crear un archivo de mecanografía separado para los módulos específicos del nodo que quería usar. Desafortunadamente, es un truco.

danpantry en 14 ago. 2016

Terminé eliminando webpack-env por completo, ya que solo necesitaba escribir una vez en todo mi proyecto para eso. Ojalá siga así. Probé su solución, pero realmente no me gusta contaminar mis archivos con referencias tanto como sea posible. Gracias por la respuesta

Saurabh Sharma / Ingeniería de calidad
[email protected] / (925) -878-5722
Yammer, Microsoft
http://www.foklepoint.com

El 14 de agosto de 2016, a las 7:08 a.m., Dan [email protected] escribió:
La forma en que lo "resolví" fue crear un archivo de mecanografía separado para los módulos específicos del nodo que quería usar. Desafortunadamente, es un truco.
-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

foklepoint en 14 ago. 2016

👍1

Claro, yo tampoco :( Pero necesitaba ese módulo, lamentablemente. @Foklepoint

danpantry en 15 ago. 2016

pero ¿qué pasa si @types/node es una dependencia de otra dependencia (por ejemplo, fs-extra , jsdom , shelljs , tape )?
también terminó eliminando webpack-env y