Utilisez-vous un autre outil de regroupement comme browserify ou webpack sur la sortie générée ? ou vous attendez-vous à ce que cela s'exécute directement sur le nœud ?

Si ce comportement est voulu, alors comment les cartes de chemin peuvent-elles être utilisées pour résoudre l'enfer d'importation relative en conjonction avec le nœud ?

Eh bien et pour ajouter du contexte, "paths" est conçu pour être utilisé avec des chargeurs qui permettent le remappage, contrairement au Node.js require() . Le comportement prévu est de permettre à TypeScript de résoudre les informations de type pour divers ID de module utilisés par divers chargeurs, et non de réécrire les ID de module. Fondamentalement, il ne fait pas ce que vous pensiez qu'il faisait. À mon avis, il ne devrait pas non plus avoir la capacité de refléter les stratégies de résolution des chargeurs.

@mhegazy Je m'attendais à ce qu'il fonctionne directement avec node. C'est pour une application backend. @kitsonk a -t-il raison de dire que cela fonctionne comme prévu et que le script ne réécrira pas les chemins des modules ?

oui, c'était l'intention - d'atténuer l'inadéquation entre l'exécution et l'expérience de conception lorsque le module (tel qu'il est écrit par l'utilisateur) peut être résolu lors de l'exécution mais n'a pas été trouvé par le compilateur. À ce stade, le compilateur suppose toujours que l'ID de module fourni par l'utilisateur est correct et n'essaie jamais de le modifier.

réponse similaire https://github.com/Microsoft/TypeScript/issues/9910#issuecomment -234729007

D'accord, merci. Il pourrait être utile de mieux documenter cela afin d'éviter que davantage de personnes ne soient confuses. J'utilise maintenant https://www.npmjs.com/package/module-alias pour le faire fonctionner avec node.

Appréciant la position de TS, voici une solution simple au cas d'utilisation de 90 % pour ceux d'entre nous qui utilisent node, mais qui veulent la commodité d'utiliser des appels baseUrl relatifs require() sans aucun problème.

Cette solution accroche l'appel require() du nœud et résout les requêtes en utilisant le nom de répertoire "main" pour imiter baseUrl . Il suppose donc que l'option de compilation baseUrl a également été définie sur le même répertoire où se trouvait la source "main.ts".

Pour l'utiliser, collez ce petit morceau de code en haut de votre "main.ts".

import * as path from 'path'
import * as fs from 'fs'
(function() {
  const CH_PERIOD = 46
  const baseUrl = path.dirname(process['mainModule'].filename)
  const existsCache = {d:0}; delete existsCache.d
  const moduleProto = Object.getPrototypeOf(module)
  const origRequire = moduleProto.require
  moduleProto.require = function(request) {
    let existsPath = existsCache[request]
    if(existsPath === undefined) {
      existsPath = ''
      if(!path.isAbsolute(request) && request.charCodeAt(0) !== CH_PERIOD) {
        const ext = path.extname(request)
        const basedRequest = path.join(baseUrl, ext ? request : request + '.js')
        if(fs.existsSync(basedRequest)) existsPath = basedRequest
        else {
          const basedIndexRequest = path.join(baseUrl, request, 'index.js')
          existsPath = fs.existsSync(basedIndexRequest) ? basedIndexRequest : ''
        }
      }
      existsCache[request] = existsPath
    }
    return origRequire.call(this, existsPath || request)
  }
})()

Si vous allez utiliser le package module-alias mentionné par mika-fischer, notez que les chemins que vous enregistrez pour le package ne doivent pas se terminer par / , et les chemins sont relatifs au chemin où package.json est (c'est peut-être évident mais c'est bien de le préciser),

Donc, si vous avez ceci dans votre fichier tsconfig :

"outDir": "./dist",
"baseUrl": ".",
"paths": {
  "foo/*": ["./src"]
}

Vous devez enregistrer ceci dans votre package.json :

"_moduleAliases": {
  "foo": "dist"
}

Eh bien et pour ajouter du contexte, "paths" est conçu pour être utilisé avec des chargeurs qui permettent le remappage, contrairement à Node.js require(). Le comportement prévu est de permettre à TypeScript de résoudre les informations de type pour divers ID de module utilisés par divers chargeurs, et non de réécrire les ID de module. Fondamentalement, il ne fait pas ce que vous pensiez qu'il faisait. À mon avis, il ne devrait pas non plus avoir la capacité de refléter les stratégies de résolution des chargeurs.

Je suis arrivé ici après avoir perdu du temps à essayer de le mettre en place dans un grand projet.
Si ce comportement ne change pas, le moins que vous puissiez faire est de mettre à jour la documentation avant de fermer ce problème.
La documentation officielle https://www.typescriptlang.org/docs/handbook/module-resolution.html#path -mapping%20docs ne dit rien sur l'utilisation de "chargeurs permettant le remappage".

installez et exécutez "tspath" dans votre dossier de projet... https://www.npmjs.com/package/tspath

@ef-carbon/tspm

Vous pouvez également essayer "momothepug/tsmodule-alias" pour la résolution du chemin d'alias :

https://www.npmjs.com/package/@momothepug/tsmodule-alias

Seul https://www.npmjs.com/package/module-alias a fonctionné pour moi...

J'ai moi aussi réussi à faire fonctionner cela avec module-alias, avec l'inconvénient que je dois garder une trace de mes alias à la fois dans tsconfig.json et package.json. Quelqu'un a-t-il trouvé une solution plus simple ?

La solution indiquée par @mattyclarkson fonctionne également, mais je n'ai pas trouvé de moyen de l'utiliser côte à côte avec ts-node. Des idées?

Jetez un œil à https://github.com/momoThePug/tsmodule-alias

2018-05-31 15:04 GMT-05:00 edufschmidt [email protected] :

J'ai aussi réussi à faire fonctionner cela avec module-alias, avec l'inconvénient
que je dois garder une trace de mes alias à la fois dans tsconfig.json et
package.json. Quelqu'un a-t-il trouvé une solution plus simple ?

La solution pointée par @mattyclarkson
https://github.com/mattyclarkson fonctionne également, mais je n'ai pas trouvé de moyen
de l'utiliser côte à côte avec ts-node. Des idées?

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393662306 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ACKT9JWIkb0Wekz0H_Z3zKXvoE-49EIBks5t4EzkgaJpZM4J6vZQ
.

Merci @DanyelMorales , c'est vraiment pratique.

de rien! :)

2018-05-31 16:35 GMT-05:00 edufschmidt [email protected] :

Merci @DanyelMorales https://github.com/DanyelMorales , c'est vraiment
pratique.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393688075 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ACKT9GNo30wNv4ZWzSwm_Lv4vesLPI3xks5t4GIzgaJpZM4J6vZQ
.

Quelqu'un peut-il me dire à quoi sert cette fonctionnalité si les noms de chemin émis sont en fait incorrects ? C'est-à-dire que si le compilateur TypeScript en est satisfait, mais que le résultat final n'est pas exécutable, quel est le cas d'utilisation de cette fonctionnalité ?

Comment faire un mappage de chemin relatif pour des éléments qui ne sont PAS des modules, c'est-à-dire qui ne sont pas importés ?

Dans un script de nœud qui lit un certain répertoire par rapport au fichier source, j'avais l'habitude de faire :

const starterDir = path.resolve(__dirname, './templates/starter')

puisque typescript compile le script et l'écrit dans un autre répertoire (basé sur config), __dirname ne conduira plus à la résolution de chemin ci-dessus. Quelle serait une solution à cela?

Comment faire un mappage de chemin relatif pour des éléments qui ne sont PAS des modules, c'est-à-dire qui ne sont pas importés ?

C'est vraiment "comment puis-je utiliser la question Node.js et TypeScript" et bien mieux posée dans Gitter.im ou StackOverflow.

J'adore TypeScript mais c'est de la folie.

Je ne comprends pas. Même si je connais peu la base de code TS, cela ne devrait pas être difficile à mettre en œuvre. Je viens de commencer à utiliser un projet partagé avec le client et le serveur... pourquoi TS présente-t-il la fonctionnalité des chemins en premier lieu, puis me fait sauter à travers des cerceaux pour l'utiliser réellement ? Pourquoi TS suppose-t-il que je souhaite utiliser un bundler/loader avec chaque projet que je réalise ? J'essaie d'utiliser TS pour simplifier mes projets, pas d'ajouter plus de bibliothèques d'outils pour compenser une fonctionnalité TS implémentée à 90%.

Je suis d'accord avec toi. Je pense que TS a été développé pour le frontend, car webpack
implémente déjà assez bien les chemins d'alias ts, et avec Requirejs est également
la même chose. Mais pour les projets Nodejs, c'est tellement difficile. :(

Le juil., 20 sept. de 2018 02:50, Josh Pike [email protected]
écrit :

Je ne comprends pas. Même avec moi connaissant peu la base de code TS, cela
ne devrait pas être difficile à mettre en œuvre. Je viens de commencer à utiliser un projet partagé
avec le client et le serveur ... pourquoi TS présente-t-il la fonctionnalité des chemins dans
la première place, puis me fait sauter à travers des cerceaux pour l'utiliser réellement ? Pourquoi
est-ce que TS suppose que je veux utiliser un bundler/loader avec chaque projet que je
Fabriquer? J'essaie d'utiliser TS pour simplifier mes projets, pas en ajouter plus
bibliothèques d'outils pour compenser une fonctionnalité TS implémentée à 90 %.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-423077950 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ACKT9DD_z4KOHpfwddTomMXujEsza9tQks5uc0jbgaJpZM4J6vZQ
.

+1 !

webpack peut m'aider à résoudre les cartes de chemin (ou un autre outil comme babel-plugin-module-resolver ) mais pas les déclarations ( .d.ts ) .

Tous les chemins dans la déclaration ne sont pas résolus.

J'ai également rencontré ce problème. Il semblait logique que le code émis inclue des mappages de chemin. Recours à module-alias . Mais +1 pour que Typescript fournisse éventuellement cette fonctionnalité.

Cela ne peut-il pas simplement être ajouté en tant qu'option du compilateur? Il s'agit clairement d'une demande populaire. Ne connaissant rien au fonctionnement du compilateur, son implémentation ne devrait-elle pas être super simple ? Pourquoi nous forcer à sauter à travers des cerceaux ailleurs alors que cela peut être si facilement résolu directement avec le compilateur TypeScript, là où cela a le plus de sens ?

+1

Vous pouvez compiler des importations TypeScript absolues et basées sur un chemin vers des fichiers Javascript relatifs à l'aide de ts-transformer-imports et ttypescript

J'ai créé une solution au moment de la compilation où vous pouvez continuer à utiliser tsc . https://github.com/joonhocho/tscpaths

Microsoft/TypeScript#15479 (commentaire)

Je viens d'être frappé par ce problème lorsque j'essaie d'obtenir vue-cli pour générer des fichiers d.ts où il y a beaucoup de import {foo} from "@/some/folder/foo" et les fichiers d.ts générés ne résolvent pas l'alias.

D'après la recherche générale et l'examen de ce fil et d'autres, il semble que la réaction instinctive soit "ce n'est pas un problème à résoudre pour TS", mais j'implore l'équipe de changer cette position comme actuellement si vous utilisez un alias de chemin personnalisé (complètement valide et approche recommandée pour les projets complexes), vous ne pouvez tout simplement pas utiliser de générer des fichiers d.ts (sans un processus de construction tiers personnalisé), donc je dirais que le compilateur Typescript devrait également résoudre ces alias dans le processus de fichier de déclaration.

Le travail des compilateurs consiste à générer des fichiers javascript ET d.ts valides pour vos fichiers dactylographiés, et cela ne fonctionne tout simplement pas dans ce scénario valide (en utilisant l'alias de chemin dans les fichiers tsconfig).

Je suis un peu confus sur cette question. Il a été fermé et étiqueté « Travailler comme prévu ». Dois-je comprendre que Typescript est destiné à produire une source invalide ? Cela semble étrange.

Les mendiants ne peuvent pas être des sélecteurs, mais l'utilisation de Typescript évite de nombreux aspects frustrants de vanilla JS et je compte les importations relatives ('../../../../../utils/parser') comme l'un d'entre eux. Ce serait incroyable si Typescript pouvait les nettoyer !

@codeitcody On dirait. C'est stupide que cela produise quelque chose qui ne fonctionne tout simplement pas sans un package tiers, mais c'est la réalité.

Eh bien, n'est-ce pas un problème agréable à tomber.

Il semble très contre-productif d'avoir une fonctionnalité qui rend essentiellement votre application inutilisable sans sauter à travers des cerceaux (c'est-à-dire installer plus de dépendances pour contourner le problème).

Ce problème existe depuis 2 ans et n'a pas de mot officiel sur sa mise en œuvre ou non.

Considérant que cela est nécessaire et que les fonctionnalités de base permettent d'utiliser l'une des meilleures fonctionnalités de TypeScript dans vos projets Node.js, la façon dont il est traité est assez horrible.

@mhegazy Pouvez-vous ou quelqu'un d'autre nous faire savoir si maintenant deux ans plus tard, l'équipe TypeScript pourrait peut-être revoir cela et reconsidérer?

webpack peut m'aider à résoudre les cartes de chemin (ou un autre outil comme babel-plugin-module-resolver ) mais pas les déclarations ( .d.ts ) .

Tous les chemins dans la déclaration ne sont pas résolus.

Existe-t-il un moyen d'y parvenir? J'ai une bibliothèque de composants de réaction personnalisée et j'ai eu cette erreur en essayant d'utiliser paths pour un alias. Je fais les 2 bundles avec rollup et les types avec --emitDeclarationOnly

Je ne peux pas utiliser module-alias car il dit:

AVERTISSEMENT : ce module ne doit pas être utilisé dans d'autres modules npm car il modifie le comportement requis par défaut !

Aidez-nous à voter pour ce message sur Reddit : https://www.reddit.com/r/typescript/comments/a07jlr/path_maps_cannot_be_resolved_by_tsc_works_as/
Je ne sais pas pourquoi il a besoin de cette énorme discussion ici. Il devrait être facile de résoudre ce bug. Une option dans tsconfig et chacun peut décider s'il veut le comportement actuel (pour une raison quelconque) ou une approche de travail.

Nous avons eu le même problème chez Dropbox et avons ouvert ce transformateur https://github.com/dropbox/ts-transform-import-path-rewrite

J'ai eu la même expérience plusieurs fois maintenant, je m'attends à ce que l'alias de chemin soit résolu mais j'oublie toujours que je dois installer module-alias, mettre à jour package.json et l'importer dans le fichier principal. Ce serait génial si cela était géré dans l'étape de compilation par Typescript.

Aie. C'est un vrai coup dur pour TypeScript. Où est le sens là-dedans ?

ps Pouvons-nous ne pas simplement commenter +1

Bienvenue au club @def14nt. Nous sommes un groupe de rêveurs heureux, les yeux étoilés alors que nous regardons vers un avenir meilleur, attendant patiemment le jour où TypeScript implémentera l'option de compilateur simple et sensée pour nous faciliter la vie. Lorsque ce jour sera enfin arrivé, assurez-vous de vérifier dans le ciel les corps roses et corpulents des cochons alors qu'ils s'envolent majestueusement vers le coucher du soleil sur leurs nouvelles ailes.

Lol, je vais juste installer une extension npm pour quelque chose que l'équipe TypeScript pourrait ajouter. Peut-être devraient-ils arrêter d'ajouter de plus en plus d'améliorations et ajouter des fonctionnalités aussi basiques.

@mika-fischer
Comment utiliser https://www.npmjs.com/package/module-alias pour qu'eslint s'arrête pour avertir du 'Chemin non résolu '@root/bla/bla' (dans les fichiers JS) ? Et comment activer la saisie semi-automatique pour de tels chemins dans WebStorm et VS Code ?

Pour moi, l'auto-complétion des importations fonctionne dans VSCode par défaut dans les projets dactylographiés.

@bobmoff Oui, il semble que tout soit bon pour importer des fichiers TS à partir de fichiers TS.
Mais la saisie semi-automatique et la navigation pour `require('@root/bla/bla') à partir des fichiers TS ne fonctionnent pas.

Je souhaite traduire mon projet JS en TS et je pensais pouvoir renommer les fichiers js en ts un par un.
Maintenant, je me rends compte que c'est si difficile et non pris en charge ni par ts ni par les IDE, et je devrais renommer tous mes fichiers js en ts à la fois.

Parce que si je renomme un seul fichier JS en TS, tous les chemins relatifs dans le répertoire build sont devenus cassés (je devrais probablement utiliser "allowJs: true", mais j'ai un projet avec 2 gigaoctets de fichiers JS, c'est ainsi bizarre de les compiler dans le répertoire de construction »).
Ok, j'essaie de résoudre ce problème par des alias de module, et la navigation et l'auto-complétion de mon IDE cessent de fonctionner et eslint avertit d'environ 100500 "chemins non résolus". Je déteste déjà un peu TS, il semble que la migration pour les gros projets JS n'est pas si facile que le disent les gens du marketing TS. Il semble que la migration des projets backend JS vers golang soit plus simple :)

J'utilise avec succès tscpaths comme solution de contournement.

Moi aussi. Je recommande vraiment tscpaths . Cela fonctionne comme prévu.

Ma solution simple:

node -r ts-node/register/transpile-only -r tsconfig-paths/register index.js

Ou avec le pm2 process.yml

apps:
  - name: 'my-app'
    script: './dist/index.js'
    instances: 'max'
    exec_mode: 'cluster'
    out_file : '/dev/null'
    error_file : '/dev/null'
    node_args: ['--require=ts-node/register/transpile-only', '--require=tsconfig-paths/register']
    env_production:
      NODE_ENV: production

Je viens de tomber dessus, parfois TypeScript peut être une vraie douleur dans le cul.

Je ne comprends vraiment pas pourquoi ce fil s'éternise...
Nous connaissons tous le "path hell", et que vous (en utilisant des alias) pouvez
vraiment propre
ce gâchis, tout le monde dans ce fil le sait !

Les alias sont interprétés par le compilateur TypeScript, il compile exactement
Comme il se doit,
il ne devrait certainement pas fouiller dans le javascript résultant, si
vous voulez utiliser
alias, vous devrez résoudre cela vous-mêmes !

....ou lancer des fils de discussion chez Apple, Google et Microsoft
leur demandant d'implémenter des fonctionnalités dans leurs moteurs JavaScript afin que
ils peuvent
interprétez vos alias ;-)

Le compilateur TypeScript fait exactement ce qu'il doit faire !

Si vous travaillez dans le monde angulaire, la route est pavée, si vous voulez
lancez votre
code directement dans Node, vous aurez besoin d'un outil pour résoudre les chemins, et j'ai
fabriqué
un tel outil juste pour vous, il est utilisé en production depuis plus d'un an maintenant,
C'est être
utilisé par le plus grand journal ici en Suède, j'ai fait cela pour que vous puissiez
aller nu
os avec Node, je n'essaie pas de vendre quoi que ce soit ici, je ne gagne pas d'argent
à partir de ça :)

Et oui, il existe des outils comme "tsmodule-alias" et des hacks similaires, vous pouvez
le faire fonctionner réellement
si vous êtes très très prudent, mais c'est un gâchis, il existe des solutions de contournement en utilisant
nœud ts,
scripts shell etc etc... yadda yadda

J'ai finalement senti que ça suffit, alors je me suis enfermé et j'ai fait
TsPath
les alias de compilation

> npm install -g tspatj

monprojet> tsc

monprojet> tspath

ou

monprojet> tspath --f

sans tête (très utile sur le serveur de build)

et puis vous avez terminé, vos fichiers javascript ont maintenant le
chemins relatifs corrects, n'est-ce pas ce que nous voulons ici ?

Acclamations! :)

https://www.npmjs.com/package/tspath

Le dimanche 13 janv. 2019 kl 22:20 skrev Fabio Spampinato <
[email protected]> :

Je viens de tomber dessus, parfois TypeScript peut être une vraie douleur dans le
cul.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-453866553 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAy_7JYrwYo3KOLxpLWP0np5JVz2kQzks5vC6MogaJpZM4J6vZQ
.

@duffman

Les alias sont interprétés par le compilateur TypeScript, il compile exactement
comme il se doit, il ne devrait certainement pas fouiller dans le javascript résultant, si
vous voulez utiliser des alias, vous devrez résoudre ce problème vous-mêmes !

Fortement en désaccord. À moins que vous ne plaisantiez, je ne pourrais vraiment pas dire.

TypeScript doit compiler le code qui _fonctionne_ sans avoir besoin d'un outil tiers pour terminer le travail qui n'a été que partiellement implémenté dans le compilateur natif.

Le compilateur TypeScript fait exactement ce qu'il doit faire !

Si ce fil était plein de personnes demandant que tsc fasse également de la minification ou quelque chose du genre, je serais d'accord avec vous. Cependant ce n'est pas le cas. Ce sont des gens qui demandent que le compilateur génère du code exécutable. Je ne pense vraiment pas que ce soit trop demander à un compilateur, n'est-ce pas ?

Et il génère du code exécutable si vous n'utilisez pas de fonctionnalités qui sont
non pris en charge par les moteurs JavaScript, cela devrait avoir beaucoup de sens
là, par exemple : blâmeriez-vous le compilateur C++ si votre application
utilise des bibliothèques de liens dynamiques et que le programme ne fonctionnera pas sur une machine
qui ne les a pas installés ?

C'est une fonctionnalité qui peut être utilisée si vous gérez les chemins relatifs,
en assumer la responsabilité comme Angular le fait avec WebPack ou comme je le fais avec
tous mes projets TypeScript avec TSPath !

Ne les utilisez pas si vous ne comprenez pas comment mettre en place un environnement de travail,
Je ne pense vraiment pas que ce soit la responsabilité de Microsoft ici, ils
a fourni une fonctionnalité et voici comment cela fonctionne,
cela peut ne pas fonctionner comme vous le souhaitez ou vous attendre à ce qu'il fonctionne, mais cela ne fait pas
c'est faux!

Aussi, je suis curieux, laissez-vous sérieusement cela vous empêcher de
développer avec TypeScript ?

Den mån 14 janv. 2019 kl 21:34 skrev Robert Main [email protected] :

Le compilateur TypeScript fait exactement ce qu'il doit faire !

Si ce fil était plein de personnes demandant que tsc le fasse également
minification ou quelque chose du genre, je suis d'accord avec vous. Cependant ce n'est pas le cas. C'est
les personnes demandant que le compilateur génère du code exécutable. je vraiment
ne pensez pas que ce soit trop demander à un compilateur, n'est-ce pas ?

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454151277 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAy_7FeuOJAnI9bXYSVgf_YghJluTyGks5vDOnEgaJpZM4J6vZQ
.

C'est une fonctionnalité qui peut être utilisée si vous gérez les chemins relatifs, en prenez la responsabilité comme Angular le fait avec WebPack ou comme je le fais avec tous mes projets TypeScript avec TSPath !

Il s'agit d'une fonctionnalité qui fait que le compilateur produit du code cassé, un code qui pourrait fonctionner s'il n'écrivait qu'une seule ligne de code pour résoudre correctement ces chemins.

Le fait que TS ait besoin d'un bundler externe juste pour que le code produit puisse être exécuté est tout simplement ridicule.

Et il génère du code exécutable si vous n'utilisez pas de fonctionnalités qui sont
non pris en charge par les moteurs JavaScript,

J'ai toujours compris que TypeScript était censé compiler en JavaScript. Si vous me dites que certaines fonctionnalités ne sont pas prises en charge par les moteurs JavaScript, pourquoi sont-elles exactement là ?

blâmeriez-vous le compilateur C++ si les bibliothèques de liens dynamiques de votre application et que le programme ne s'exécute pas sur une machine ne les ont pas installées ?

Non, mais je le blâmerais s'il me permettait de créer un lien vers un autre code C++ qui n'existait pas réellement sans erreur ni avertissement du compilateur.

Vous ne comprenez vraiment pas cela, n'est-ce pas ? Le code n'est pas cassé, si c'est
cassé c'est parce que vous avez configuré le compilateur
pour générer du code que votre "plateforme" ne supporte pas, dans ce cas,
pseudonymes !

Dans votre cas, n'utilisez pas d'alias, "vous" ne les supportez pas, sérieusement !

Même s'il s'agit d'un correctif d'une ligne (bien sûr, ce n'est pas le cas), c'est un
question de ce qu'un compilateur devrait et
ne devrait pas faire! Cette fonctionnalité a été ajoutée afin de SOUTENIR LES CHARGEURS non
dans l'autre sens, lisez
sur Path Mapping dans la documentation officielle, donc encore une fois, vous l'utilisez
tort!

Encore une fois, cette fonctionnalité est destinée aux chargeurs/résolveurs, vous avez mal compris comment elle
fonctionne, donc non, Microsoft
ne doit pas modifier le compilateur afin que vous puissiez coller des alias sans
environnement qui le supporte !

Den tis 15 janv. 2019 kl 04:41 skrev Fabio Spampinato <
[email protected]> :

C'est une fonctionnalité qui peut être utilisée si vous gérez les chemins relatifs,
en assumer la responsabilité comme Angular le fait avec WebPack ou comme je le fais avec
tous mes projets TypeScript avec TSPath !

Il s'agit d'une fonctionnalité qui fait que le compilateur produit du code cassé, du code qui
pourrait fonctionner s'ils n'écrivaient qu'une seule ligne de code pour résoudre ces
chemins.

Le fait que TS ait besoin d'un groupeur externe juste pour que le code produit
peut être exécuté est tout bonnement ridicule.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454256799 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAy_zuWKV0qzzWt6_jZNgDLFt1TA0tMks5vDU3vgaJpZM4J6vZQ
.

Ils sont là depuis que les chargeurs utilisent le mappage de chemin, c'est pourquoi il est pris en charge !
Et puisque vous insistez (comme moi) pour les utiliser sans Loader, quel est le
problème avec
utiliser un outil pour pouvoir utiliser la fonctionnalité ?

Den tis 15 janv. 2019 kl 05:10 skrev Robert Main [email protected] :

Et il génère du code exécutable si vous n'utilisez pas de fonctionnalités qui sont
non pris en charge par les moteurs JavaScript,

J'ai toujours compris que TypeScript était censé compiler pour
JavaScript. Si vous me dites que certaines fonctionnalités ne sont pas prises en charge par
Les moteurs JavaScript alors pourquoi sont-ils exactement là ?

blâmeriez-vous le compilateur C++ si le lien dynamique de votre application
bibliothèques et que le programme ne fonctionnera pas sur une machine ne les a pas
installée?

Non, mais je le blâmerais si cela me permettait de créer un lien vers un autre code C++ qui ne le faisait pas
existent réellement sans erreur ni avertissement du compilateur.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454260977 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAy_25-ZmS235i1Ic7mvSzEt2QJDX6Bks5vDVTAgaJpZM4J6vZQ
.

Écoute, je vois ton point. Je fais. Mais une partie du travail des compilateurs consiste à vérifier les choses une dernière fois. Au mieux, le code qui compile mais ne s'exécute pas est un comportement incohérent et lorsque j'ai lu ce problème pour la première fois, la documentation semblait suggérer un comportement qui n'existe clairement pas

Veuillez m'indiquer cette section de la documentation.

c'est le 15 janv. 2019 kl. 05:31 skrev Robert Main [email protected] :

Écoute, je vois ton point. Je fais. Mais une partie du travail des compilateurs consiste à rester sain d'esprit
vérifie les choses une dernière fois. Au mieux, le code qui compile mais ne s'exécute pas est
comportement incohérent et quand j'ai lu ce problème pour la première fois,
la documentation semblait suggérer un comportement qui n'existe clairement pas

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454263854 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAy_8e5v8IV-ynmjRTeoC3cp5llwnsIks5vDVm8gaJpZM4J6vZQ
.

Cette fonctionnalité a été ajoutée afin de SOUTENIR LES CHARGEURS non
dans l'autre sens, lisez
sur Path Mapping dans la documentation officielle, donc encore une fois, vous l'utilisez
tort!

https://austinknight.com/wp-content/uploads/2015/04/DesignVSUX.jpeg

@duffman Vous ne voyez pas que les gens ici veulent juste cette fonctionnalité ??? Vous dites à tout le monde qu'il est trop stupide pour comprendre comment cette "fonctionnalité" doit être utilisée. OK - vous pouvez voir cela de cette façon mais qui sait - c'est peut-être l'inverse...

Au passage, mon avis est le suivant :

Comme les alias sont intégrés dans le compilateur et la compilation du projet avec eux est OK. Cela peut faire penser aux utilisateurs que cela fonctionne comme il le suggère (et ce problème est à peu près une bonne preuve que j'ai raison). Cela semble même illogique - pourquoi quelque chose fonctionne dans l'éditeur "officiel" (vscode - en particulier lors de l'utilisation de la fonction "importation automatique", vscode utilise un chemin alias), pourquoi le copieur fonctionne également correctement, lorsque le code résultant ne fonctionne pas ? Dire que "le moteur js ne le supporte pas" me donne envie de demander encore plus - TS n'était-il pas censé atténuer certains des "problèmes" JS?

Je m'attendrais à l'une des deux solutions de ceci:
1) Remplacer correctement les importations avec des alias
2) Affichage d'un avertissement

Dire "c'est un comportement correct" est, je pense, faux. Ce n'est pas. TS n'est pas un langage d'assemblage, pas même un C/C++.

L'équipe de développement devrait ajouter la prise en charge de la résolution d'alias. Je suggère d'ajouter un
clé pour la résolution du compilateur dans tsconfig.

Ce serait bien Microsoft !!!!!

Nous vous en supplions, nous avons besoin de votre aide pour améliorer les applications avec alias.

:( tout le monde ici est triste et en colère(, et affamé) à cause du décalage de
cohérence. Le manuscrit est génial, j'adore...

Nous aimons ça!

Meilleures salutations à un développeur sans-abri...

El mar., 15 de ene. de 2019 08:02, Mike S. [email protected]
écrit :

Au passage, mon avis est le suivant :

Les alias sont intégrés dans le compilateur une compilation est OK. Cela peut rendre les utilisateurs
pense que cela devrait fonctionner comme ils le pensent (et ce problème est à peu près
bonne preuve que c'est vrai). Cela semble illogique - pourquoi quelque chose fonctionne dans
éditeur "officiel" (vscode - en particulier lors de l'utilisation de la fonction "importation automatique",
vscode utilise un chemin alias), pourquoi le copieur fonctionne également correctement, lorsque le code résultant
ne fonctionne pas? Dire "le moteur js ne le supporte pas" me donne envie de demander
encore plus - TS n'était-il pas censé atténuer certains des "problèmes" de JS ?

Je m'attendrais à l'une des deux solutions de ceci:

1. Remplacer correctement les importations avec des alias
2. Affichage d'un avertissement

Dire "c'est un comportement correct" est, je pense, faux. Ce n'est pas. TS n'est pas
langage d'assemblage, pas même un C/C++.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454384357 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ACKT9OqexgOaHH1vDFuRcO7U_r2DEC23ks5vDdFbgaJpZM4J6vZQ
.

. TS n'est pas un langage d'assemblage, pas même un C/C++.

Je ne comprends vraiment pas ce que vous essayez de souligner en établissant que TS n'est pas C++, la plupart d'entre nous en sont bien conscients je pense !

Nous avons également établi que le mappage d'alias/chemin est utilisé en production partout dans le monde, donc naturellement, VS Code devrait le prendre en charge, mais ce n'est toujours pas un argument pour MS pour concevoir le compilateur adapté à votre configuration !

Ce que j'ai du mal à comprendre, c'est pourquoi vous continuez, le compilateur fonctionne comme il est censé fonctionner, encore une fois, lisez la documentation qui indique clairement à quoi sert la fonctionnalité !

Je veux dire que vous pouvez configurer un environnement de développement TS fonctionnel avec des alias de chemin en 2 minutes environ, si vous ne voulez pas utiliser WebPack, vous pouvez utiliser TSPath pour résoudre tous les chemins dans tous les fichiers js en 1 seconde, ajoutez-le au package .json en tant que script d'exécution et vous n'avez même pas à y penser, le problème n'existe pas, le compilateur reste tel qu'il était censé fonctionner et vous pouvez continuer, hourra heureux ! ?

Ou s'il est si important pour vous que le compilateur le fasse pour vous, alors je vous suggère de bifurquer le compilateur et de l'implémenter vous-même, peut-être que ce serait un grand succès ou peut-être que les gens sont heureux comme ils sont depuis qu'ils ont mis en place leurs environnements pour prendre en charge les alias.

Invocation des cinq meilleurs contributeurs TypeScript : @ahejlsberg @andy-ms @DanielRosenwasser @sandersn @sheetalkamat

L'équipe TypeScript pourrait-elle reconsidérer ce problème ? Je pense que ce fil offre une discussion utile sur les deux points de vue et compte tenu de sa popularité récente et du temps qui s'est écoulé, il devrait être réexaminé.

Le statut de ce problème ne m'a laissé d'autre choix que de rétrograder TS au rôle de vérificateur de type uniquement.
Babel a maintenant un support décent pour la syntaxe TS et avec babel-plugin-module-resolver fait le travail d'émettre du code de travail pour ce cas d'utilisation très bien.
Le seul inconvénient est la duplication de bits de configuration à partir de tsconfig.json car Babel ne se soucie pas des configurations TS. Mais c'est un prix acceptable pour travailler sur des chemins absolus dans des projets de nœuds et en prime, j'obtiens tout l'écosystème avec des choses brillantes comme les macros babel.

C'est la configuration minimale que j'ai eue en remplacement du compilateur tsc :

• npm install --save-dev @babel/cli @babel/core @babel/preset-env @babel/preset-typescript babel-plugin-module-resolver @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread
• en package.json :
  tsc -> tsc && babel ./src --out-dir ./dist --extensions ".ts,.js"
• en tsconfig.json :

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@mynamespace/*": ["src/*"]
    },
    "outDir": "./dist",
    "noEmit": true, <--
    "allowJs": true,
    "target": "ES2017",
    "module": "CommonJS",
    "lib": [
      "ES2017"
    ]
  },
  "include": [
    "./src/**/*"
  ]
}

• en .babelrc :

{
  "presets": [
    "@babel/preset-typescript",
    ["@babel/preset-env", {
      "targets": {
        "node": true
      }
    }]
  ],
  "plugins": [
    ["module-resolver", {
      "root": ["./src"],
      "alias": {
        "@mynamespace": "./src"
      },
      "extensions": [".js", ".ts"]
    }],
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-object-rest-spread"   
  ]
}

Je veux juste utiliser du tapuscrit avec un chemin absolu, mais il semble que je doive configurer webpack ou babel ou quelque chose, c'est trop difficile d'atteindre cette fonctionnalité simple, ça devrait être plus facile 😞

Je reconnais ce problème, je ne suis pas sûr d'avoir été au courant de ce problème spécifique
problème dû à ma propre configuration personnelle, ou peut-être que je l'étais :) ce n'est pas un super
correctif lourd, le correctif sera simplement de simplement (aveuglément) faire confiance au distPath,
qui est en fait un code de moins en moins simple que la solution actuelle, je vais
essayez d'avoir un correctif disponible d'ici demain...

Le mån 28 janv. 2019 kl 15:59 skrev 叶伟伟[email protected] :

Je veux juste utiliser un tapuscrit avec un chemin absolu, mais il semble que je doive
config webpack ou babel ou quelque chose comme ça, c'est trop dur à réaliser !!!

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-458164055 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAy_1_T-An7swSND-xdBhL0HNHxQkm6ks5vHxBggaJpZM4J6vZQ
.

Laisser cela ici car un cas d'utilisation documenté réel pour le comportement actuel de paths n'a pas été mentionné dans ce fil : les packages @types/ ne rétroportent pas les fonctionnalités en ce qui concerne semver. Ils incluent cependant des types mis à jour pour les anciennes API que je peux utiliser. Par exemple, j'utilise history@2 alors que history@3 est le dernier.

"paths": {
    "history": [ "history/v2" ]
}

Le compilateur aurait besoin d'une option supplémentaire pour différencier les alias de type et les alias de "code". Si nous modifions le comportement pour émettre réellement les alias de chemin, nous devons ajouter la possibilité au compilateur de trouver la bonne version des types.

Ce n'est pas un argument contre le comportement proposé. J'aurais préféré émettre des alias et une solution de travail just™ pour la gestion des versions des types. Je voulais juste expliquer pourquoi changer cela pourrait ne pas être aussi trivial que les gens le pensent.

Pour la deuxième fois lors d'un atelier TS à l'échelle de l'entreprise, j'ai dû expliquer ce comportement insensé et embarrassant...

Sérieusement!

Quel type de compilateur de langage, en particulier celui dont l'argumentaire de vente principal est plus correct pour JavaScript, produit du code défectueux en tant que "fonctionnalité" ?!? !

Je suis désolé d'avoir semblé si frustré dans mon commentaire, mais les opinions de la communauté ici sont apparemment ignorées et minimisées à plusieurs reprises.

Regardez combien de fois cela a été référencé... Quelle perte de temps et d'attention pour tant de gens.

Je comprends votre frustration, mais beaucoup de gens pensent qu'un comportement est correct, cela ne veut pas dire que c'est la bonne chose à faire.

Les identifiants de module de réécriture TypeScript sont une pente glissante. Ce qui a été exprimé à plusieurs reprises dans ce fil, c'est que TypeScript est configurable pour modéliser le comportement d'autres résolveurs de modules et d'autres outils de construction, et non pour les remplacer ou les implémenter.

Ce n'est pas parce que TypeScript peut être configuré pour résoudre les modules de manière flexible que cela signifie que TypeScript émet un "code brisé". Certains chargeurs et bundlers qui reflètent cette configuration fonctionneraient très bien.

Si nous devions critiquer quoi que ce soit, nous pourrions reprocher à l'équipe d'avoir nommé l'option quelque chose qui pourrait avoir l'air de résoudre un problème qu'elle n'a jamais été destinée à résoudre, bien que la documentation de l'option indique clairement qu'elle ne change pas l'émission .

Parce qu'un outil particulier ne résout pas un problème que vous avez ne signifie pas toujours que c'est la faute de cet outil. Il se peut que vous n'ayez tout simplement pas tous les outils nécessaires pour résoudre votre problème.

@kitsonk tout ce que vous venez de dire est loin de la vérité.

Le problème est que TS fonctionnera d'une manière pendant le développement / les tests, et d'une autre après la fin de la compilation.

Si TS veut être un résolveur de module, il doit choisir un modèle et s'y tenir. Si j'exécute quelque chose avec ts-node , cela devrait fonctionner exactement comme si j'avais compilé du TS et l'avais exécuté avec node .

Ce n'est pas le cas, et c'est là le problème.

Peut-être que les cartes de modules atténueront la frustration à l'avenir. Mais notre position ici ainsi que les problèmes techniques que nous voulons résoudre sont assez explicites - le mappage de chemin reflète le comportement d'un schéma de résolution externe (par exemple, le mappage de chemin dans AMD et System.js, les alias dans Webpack et d'autres bundlers). Cela ne signifie pas que nous allons changer vos chemins.

Je ne pense pas qu'une discussion récente ait été constructive récemment, et je ne prévois pas non plus de changements futurs ici, donc je vais verrouiller ce problème.