Typescript: Suppression de l'erreur "Le chemin d'importation ne peut pas se terminer par une extension '.ts'"?

Supposons que vous ayez deux fichiers:
a.ts : import * as b from "./b.ts";
b.ts : export const b: number = 0;

Lorsque nous compilons a.ts , nous ne changeons pas les spécificateurs d'importation . Ainsi, la sortie a.js contiendra le même spécificateur d'importation "./b.ts", bien que probablement traduit en require("./b.ts") .
Ensuite, lorsque vous essayez d'exécuter a.js cela échouera, car il n'y aura pas de b.ts à importer, seulement b.js . (Ou sans --outDir où b.js est à côté de b.ts , cela résoudra l'importation en b.ts , puis échouera l'analyse à : number . )

Au lieu de cela, vous devez omettre l'extension de fichier de vos importations ou utiliser l'extension .js .

non ， J'utilise deno exécute le fichier。 sans compiler。

@ hooper-hc
Je pense que nous pouvons définir tsconfig comme une solution temporaire comme celle-ci:

{
  "compilerOptions": {
    "module": "amd",
    "target": "esnext",
    "baseUrl": ".",
    "paths": {
      "http://*": ["../../../.deno/deps/http/*"],
      "https://*": ["../../../.deno/deps/https/*"],
      "*.ts": ["*"]
    }
  }
}

J'utilise aussi deno. J'ai trouvé que commenter // @ts-ignore chaque ligne d'une importation fonctionne.

// @ts-ignore
import coerceToArray from './journey.coerce-to-array.ts'
// @ts-ignore
import fnFree from './journey.fn-free.ts'
// @ts-ignore
import fnReduce from './journey.fn-reduce.ts'

Est-il possible de supprimer cette exigence globalement dans ts-config?

J'ai également essayé la solution de @zhmushan et cela n'a pas résolu le problème :(

@reggi supprime ./
J'espère qu'à l'avenir, nous pourrons utiliser une configuration similaire à module:deno pour simplifier l'opération.

L'équipe TypeScript serait-elle ouverte à l'ajout de "module": "deno" au tsconfig? De cette façon, nous pouvons prendre en charge l'utilisation de l'extension .ts manière native, sans avoir besoin de recourir à quelque chose comme kitsonk / deno_ls_plugin comme solution de contournement. Il pourrait également essayer de l'appliquer également, donc si vous essayez de le faire

import module from 'module';

il afficherait une erreur comme Cannot have an extensionless import with module:deno (les seules importations autorisées sont les URL complètes et les importations relatives commençant par ./ ou ../ ). Une configuration comme celle-ci pourrait également prendre en charge la recherche native de types dans le dossier $DENO_DIR/deps , car nous devons actuellement utiliser un paramètre de chemin pour contourner ce problème. En plus de cela, les importations automatiques pourraient également fonctionner correctement, car elles effectuent actuellement toujours l'importation sans extension (ce qui signifie que vous devez de toute façon la modifier manuellement).

Cela semble être un double de # 11901 qui a malheureusement été fermé et réduit au silence. Ceci est important pour Deno comme cela a été dit précédemment et j'espère que TypeScript rendra cette vérification d'extension configurable ou même mieux la supprimera complètement.

Dans la plupart des écosystèmes d'outils Javascript, vous pouvez faire des choses comme import picture from 'image.png' , qui n'est évidemment pas Javascript. L'hypothèse est que certains outils sauront comment transpiler le fichier référencé en Javascript pour que cela fonctionne correctement. Tous les types d'actifs et syntaxes alternatives, telles que JSX, fonctionnent de cette manière.

Typescript, d'autre part, attend que vous utilisiez une extension vide ou l'extension .js , ce qui est différent du fonctionnement du reste de l'écosystème. Cela provoque des frictions pour des outils comme Deno ou rollup.js qui attendent l'extension de fichier d'origine.

Si tsc voulait fonctionner plus comme le reste du monde, il pourrait autoriser .ts comme extension, puis la transformer en .js dans le cadre de la suppression des types au moment de la construction. Il s'agit évidemment d'un grand changement dans le fonctionnement du compilateur tsc. D'un autre côté, il y a une vague d'outils alternatifs basés sur Babel et Sucrase qui commencent à entrer dans l'écosystème, il y a donc peut-être un avantage à long terme à s'aligner sur la manière de faire de ces outils.

Ajout de mon vote ici pour le soutien à Deno. Le comportement actuel conduit TypeScript à résoudre tous les types importés de cette manière en any , ce qui rend le développement de logiciels pour Deno assez difficile.

Deno est une excellente idée, mais essayer de convaincre l'équipe TS de permettre explicitement à Deno de résoudre les modules de cette façon est pour moi une bataille perdue. Il est beaucoup plus facile pour Deno de le gérer simplement car (a) beaucoup plus rapide pour le faire, moins d'efforts nécessaires et (b) convaincre l'équipe TS de recâbler ses internes comme ça est une bataille très difficile.

Si tsc voulait travailler plus comme le reste du monde

TS devient de plus en plus dominant, c'est une bonne stratégie d'être aussi compatible que possible avec les conventions TS y compris leur outillage. Sinon, des projets comme Deno n'auront jamais de succès en raison de la divergence entre quelque chose d'aussi fondamental que la résolution de module

@ jpike88 Je ne suis pas d'accord. Je ne savais pas que ce problème existait. Il y avait quelques autres problèmes semi-liés que nous suivions. Ce problème ne dit rien sur l'intention de l'équipe. Elle est toujours étiquetée comme une question et on pourrait dire qu'il s'agit vraiment d'un duplicata de # 16577 ou # 18442.

Le commentaire de Ryan va cependant au cœur du problème, selon lequel ils peuvent éventuellement écrire quelque chose qui satisfait chaque hôte, ils le limitent donc à la situation la plus courante aujourd'hui, qui est la manière CJS de Node.js.

Je pense toujours (et je pensais avoir déjà dit cela dans un problème) qu'il pourrait y avoir du temps pour "moduleResolution": "literal" qui ferait ce qu'il dit sur la boîte, et permettrait à TypeScript de supposer que quel que soit l'hôte d'exécution le comprendrait out / changez les spécificateurs de module.

OK mais:

https://github.com/microsoft/TypeScript/issues/18442
En fait, j'ai commenté cela il y a deux ans, et c'est toujours après tout ce temps une proposition de la première étape.

https://github.com/microsoft/TypeScript/issues/16577
Aussi âgé de plus de deux ans, toujours au stade de «discussion». Aussi au rythme que ça va, ça n'arrivera pas de sitôt.

Je suis juste en train de sortir de l'échelle de temps que les choses se sont passées ici, et en basant leur probabilité de se produire à moyen ou même à long terme.

Ce problème a été marqué comme "Question" et n'a connu aucune activité récente. Il a été automatiquement fermé à des fins d'entretien ménager. Si vous attendez toujours une réponse, les questions sont généralement mieux adaptées au stackoverflow .

Un problème similaire se produit si vous souhaitez importer directement un fichier .mjs
par exemple import { forEach } from https://unpkg.com/[email protected]/index.mjs

C'est fermé, mais ce n'est pas corrigé.

Si quelqu'un ici cherchait simplement un moyen d'exécuter votre TypeScript dans le contexte de Node.js et Deno, sachez que Webpack + ts-loader vous permettra de conserver ".ts" dans vos importations.

J'ai ce problème chaque fois que j'importe un fichier depuis deno? une solution pour résoudre ce problème, sauf en ajoutant // @ts-ignore ?

Est-ce corrigé? L'importation sans extension ne fait pas partie du JS de toute façon, l'utilisation d'extensions ne devrait pas afficher d'erreur.

Je suis d'accord avec les commentaires ci-dessus. C'est dommage que le problème n'ait pas encore été résolu.
J'ai trouvé une extension pour vscode qui devrait aider, mais malheureusement cela ne fonctionne pas correctement.
Quoi qu'il en soit, je laisse les liens ici:
1) https://github.com/justjavac/vscode-deno
2) https://github.com/axetroy/vscode-deno

Suivant @ TicTak21 :
Les liens qu'il a mentionnés sont désormais obsolètes au profit du plugin officiel deno:
https://github.com/denoland/vscode_deno
Cette extension corrige correctement les importations .ts et URL (donc plus d'erreurs),

@danbulant Je vois toujours l'erreur en utilisant le plugin vscode_deno.

J'utilise aussi Deno mais je pense que le problème ici n'est pas de .ts vs no .ts . Il s'agit davantage de permettre à tsc d'ignorer tout numéro d'erreur. Par exemple, quelque chose comme tsc --ignore TS2691 .

L'extension Deno pour vs code est sympa, mais elle ne résout pas le problème, elle supprime simplement l'erreur dans l'éditeur. J'ai une bibliothèque que je veux construire pour deno et le navigateur, mais je ne peux pas parce que tsc lancera.

@samuelgozi
Je suis d'accord à 100%. C'est la raison principale pour laquelle je ne considère pas encore Deno comme un remplaçant du node.js sur le serveur. Un bon framework web pour Deno est déjà disponible, et seul TYPESCRIPT fait obstacle à ce beau rêve

Pour toute personne ayant des problèmes récents avec cela, je dirai que le deno_ls_plugin, malgré son archivage, a obtenu exactement le résultat dont j'avais besoin. Ce problème qui fait référence au plugin est la façon dont je l'ai découvert .

Mon cas d'utilisation spécifique est que je travaille dans un environnement avec du code dactylographié partagé entre le client et le serveur à l'aide de liens symboliques. Le serveur est écrit avec deno à l'esprit, et le client est écrit avec un script dactylographié et un phaser3 normaux. Le Bundler J'utilise, colis , peut gérer l' importation tapuscrit .ts fichiers (au moins avec parcel-bundler ^1.12.4 ). Cela laisse l'intellisense à réparer.

deno_ls_plugin fonctionne très bien pour moi, car il ne fait que corriger la résolution du module .ts . Parfait! Cela signifie que je peux importer le code partagé, et faire écrire le code partagé avec deno avant tout dans l'esprit, et patcher l'intellisense pour le côté client dactylographié des choses.

Pour commencer, j'ai exécuté la commande yarn add typescript deno_ls_plugin --dev pour l'installer. Après avoir vu que l'intellisense n'était pas corrigé, j'ai remarqué un petit texte au bas du fichier readme de deno_ls_plugin , pour utiliser la version de l'espace de travail de typescript .

Pour tous ceux qui ne savent pas trop comment faire cela, voici ce que j'ai fait:
Tout d'abord, j'ai installé deno_ls_plugin et typescript tant que dépendances de développement, et mis tsconfig.json jour deno_ls_plugin tant que plugin

{
  "compilerOptions": {
    "plugins": [{ "name": "deno_ls_plugin" }]
  }
}

Ensuite, j'ai cliqué sur un fichier dactylographié et cliqué sur la version dans le coin inférieur droit.

Ensuite, j'ai choisi de sélectionner la version dactylographiée

et a choisi la version de l'espace de travail.

Dans mon cas spécifique, j'ai également défini typescript.tsdk dans .vscode/settings.json mais je ne sais pas si j'en avais besoin.

Si quelqu'un d'autre essaie également de partager du code deno avec du code dactylographié, j'ai utilisé des liens symboliques pour créer un lien vers le code principal dans le serveur et le client, et j'avais le code à l'intérieur du lien symbolique faisant référence à un fichier deps.ts en dehors de celui-ci pour dépendances (puisque import_map est un peu meh atm) afin que la version dactylographiée puisse importer le package npm et la version deno peut importer les URL.

Espérons que ce petit message pourrait aider quiconque ayant des problèmes similaires en essayant de partager du code deno entre un projet typographique classique et un projet deno.

J'ai créé un problème de suggestion ici qui résoudrait le problème ci-dessus. Espérons que nous pourrons obtenir un élan pour que cela ou quelque chose de similaire soit mis en œuvre dans un avenir très proche.

Ce numéro doit être rouvert.

Les développeurs de Deno n'obtiennent pas le respect qu'ils méritent ici. Ils ont créé un environnement d'exécution incroyable basé sur TypeScript, mais les développeurs TypeScript n'ajouteront pas d'indicateur pour lui permettre de fonctionner correctement. Comment cette triste situation peut-elle durer si longtemps?!

Ne pas pouvoir utiliser l'extension .ts sur les importations cause une douleur et des problèmes énormes aux utilisateurs de Deno, aidez-nous!

ce n'est pas vraiment spécifique à Deno

sans possibilité de définir explicitement l'extension, de nombreux développeurs JS auront des problèmes

par exemple dans notre projet vue nous spécifions toujours des extensions, sinon nous aurons un problème dans une situation comme

./component.vue
./component.ts

import component from './component';

Pourquoi est-ce fermé? Certainement pas spécifique à Deno surtout avec la montée en puissance des mjs

Ce fil n'est PAS une question, c'est une demande de fonctionnalité. Quelqu'un peut-il corriger l'étiquette et la rouvrir? L'ajout manuel de // @ts-ignore à chaque importation n'est pas une solution acceptable.

@zraineri

J'ai lu plusieurs fils traitant de ce problème. Pour résumer, les développeurs principaux ne veulent tout simplement pas faire cela. Ils disent que cela peut casser d'autres choses et que l'algorithme d'importation est déjà assez complexe et ainsi de suite.

Considérez-moi comme fou, mais il me semble qu'il y avait une certaine solidarité d'entreprise ici. La société a dépensé beaucoup d'argent sur le nœud (npm). Et ne veut pas qu'un parvenu leur vole leurs profits de ses propres mains .. Donc je ne pense pas que vous puissiez vous attendre à beaucoup de convivialité envers deno de la part de vscode ou dactylographié

Heureusement, vous pouvez utiliser un plugin qui fait déjà plus que ce que vous demandez et qui ne fera que s'améliorer.
https://marketplace.visualstudio.com/items?itemName=denoland.vscode-deno

Mais le problème est non seulement Deno, mais aussi des js réguliers
https://github.com/microsoft/TypeScript/issues/27481#issuecomment -664401169

@Hulkmaster

Il semble que nous ayons besoin d'un nouveau manuscrit brillant. Celui-ci est coincé avec ses problèmes hérités et ne peut pas (ou ne veut pas) implémenter les importations avec des extensions. L'équipe deno semble avoir l'intention d'écrire son propre manuscrit (en rouille, je suppose :)

Je fais partie de l'équipe principale de Deno. Je suis d'accord que le compilateur TypeScript ne devrait pas s'impliquer dans la réécriture des spécificateurs de module. Les composants internes de Deno suppriment ce message de diagnostic et le plugin vscode pour Deno supprime également ce message. Ce n'est pas un obstacle pour Deno.

Croyez-moi, il n'y a pas de cabale cachée Microsoft / Node.js qui supprime Deno. L'équipe principale de TypeScript, membre de la communauté Node.js et l'équipe principale de Deno se parlent régulièrement et collaborent.

@kitsonk

Ce n'est pas un obstacle pour Deno.

mais c'est un obstacle à l' unification de deux mondes: Node et Deno. Comment puis-je écrire un texte dactylographié qui fonctionnera sur les deux plates-formes en même temps si vous avez des désaccords religieux sur l'importation de fichiers locaux avec ou sans extensions ... Je vais devoir choisir un côté

Comment puis-je écrire un texte dactylographié qui fonctionnera sur les deux plates-formes en même temps si vous avez des désaccords religieux sur l'importation de fichiers locaux avec ou sans extensions.

Ce n'est vraiment pas un problème avec TypeScript / tsc . Node.js se dirige de toute façon vers les modules explicites, et la façon dont ils abordent cela aura un impact sur les capacités de résolution des modules de tsc je soupçonne. Je crois qu'il y a des conversations continues là-bas, pour pouvoir mieux supporter ESM dans Node.js.

Faire ce que suggère ce problème n'aiderait vraiment personne. Une meilleure solution au problème a été proposée dans le # 33437.