Typescript: 방출된 코드에서 모듈 경로 맵이 확인되지 않음

에 만든 2016년 09월 12일 · 76코멘트 · 출처: microsoft/TypeScript

타입스크립트 버전: 2.0.2

암호

_tsconfig.json_

{
    "compilerOptions": {
        "target": "ES6",
        "module": "commonjs",
        "baseUrl": ".",
        "paths": {
            "foo/*": ["*"]
        }
    }
}

_app.ts_

import {Foo} from 'foo/utils';
console.log(Foo);

_utils.ts_

export const Foo = 'Foo';

예상되는 동작:

% ./node_modules/.bin/tsc && node app.js
Foo

실제 행동:

% ./node_modules/.bin/tsc && node app.js
module.js:457
    throw err;
    ^

Error: Cannot find module 'foo/utils'
    at Function.Module._resolveFilename (module.js:455:15)
    at Function.Module._load (module.js:403:25)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/home/mfischer/src/videmo/tsc-test/app.js:2:17)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)

_앱.js_

"use strict";
const utils_1 = require('foo/utils');
console.log(utils_1.Foo);

Typescript가 올바른 모듈을 찾고 있지만 방출된 코드에서 모듈 경로는 tsconfig.json 의 경로 별칭을 적용하는 대신 그대로 남아 있습니다. 분명히 노드는 모듈을 찾을 위치를 모릅니다. typescript가 모듈 경로를 해결하고 노드가 해결할 수 있는 것으로 대체할 것으로 예상했습니다.

이 동작이 의도된 경우 노드와 함께 상대 가져오기 지옥을 해결하기 위해 경로 맵을 어떻게 사용할 수 있습니까?

Working as Intended

출처

mika-fischer

👍116

가장 유용한 댓글

방출된 경로 이름이 실제로 올바르지 않은 경우 누군가 이 기능의 요점이 무엇인지 말해 줄 수 있습니까? 즉, TypeScript 컴파일러가 만족하지만 최종 결과를 실행할 수 없는 경우 이 기능의 사용 사례는 무엇입니까?

robertmain 에 2018년 06월 27일

👍100 ❤20 😄16 🎉15 😕10

모든 76 댓글

생성된 출력에 browserify 또는 webpack과 같은 다른 번들링 도구를 사용합니까? 또는 이것이 노드에서 직접 실행되기를 기대하십니까?

mhegazy 에 2016년 09월 13일

👎13

이 동작이 의도된 경우 노드와 함께 상대 가져오기 지옥을 해결하기 위해 경로 맵을 어떻게 사용할 수 있습니까?

글쎄요 그리고 컨텍스트를 추가하기 위해 "paths" 는 Node.js require() 와 달리 재매핑을 허용하는 로더와 함께 사용하도록 설계되었습니다. 의도된 동작은 TypeScript가 모듈 ID를 다시 쓰는 것이 아니라 다양한 로더에서 사용하는 다양한 모듈 ID에 대한 유형 정보를 확인할 수 있도록 하는 것입니다. 기본적으로 그것은 당신이 생각한 대로 하지 않습니다. 제 생각에는 로더의 해결 전략을 미러링할 수 있는 기능만 있어야 합니다.

kitsonk 에 2016년 09월 13일

👎29 👍2

@mhegazy 노드와 직접 작동할 것으로 예상했습니다. 백엔드 애플리케이션용입니다. 이것이 의도한 대로 작동하고 typescript가 모듈 경로를 다시 쓰지 않을 것이라는 @kitsonk 의 말이 맞습니까?

mika-fischer 에 2016년 09월 13일

👍20

네, 이것은 의도였습니다 - 모듈(사용자가 작성한 대로)이 런타임에서 해결될 수 있지만 컴파일러에서 찾지 못하는 경우 런타임과 디자인 시간 경험 간의 불일치를 완화하기 위한 것입니다. 이 시점에서 컴파일러는 항상 사용자가 제공한 모듈 ID가 정확하다고 가정하고 변경을 시도하지 않습니다.

vladima 에 2016년 09월 13일

유사한 응답 https://github.com/Microsoft/TypeScript/issues/9910#issuecomment -234729007

mhegazy 에 2016년 09월 13일

👎2

알겠습니다. 감사합니다. 더 많은 사람들이 혼동하는 것을 방지하기 위해 이것을 더 잘 문서화하는 것이 유용할 수 있습니다. 이제 https://www.npmjs.com/package/module-alias 를 사용하여 노드에서 작동하도록 합니다.

mika-fischer 에 2016년 09월 14일

👍49 ❤7 😄5

TS의 입장에 감사드리며, 노드를 사용하지만 소란 없이 baseUrl 상대 require() 호출을 사용하는 편리함을 원하는 우리를 위한 90% 사용 사례에 대한 간단한 솔루션입니다.

이 솔루션은 노드의 require() 호출을 연결하고 baseUrl 를 모방하기 위해 "main" 의 dirname을 사용하여 요청을 해결합니다. 따라서 baseUrl 컴파일러 옵션도 소스 "main.ts"가 있는 동일한 디렉토리로 설정되었다고 가정합니다.

사용하려면 이 작은 코드 덩어리를 "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)
  }
})()

papercuptech 에 2016년 12월 20일

mika-fischer가 언급한 module-alias 패키지를 사용하려는 경우 패키지에 등록하는 경로는 / 로 끝나지 않아야 하며 경로는 경로에 상대적입니다. 여기서 package.json 는 (명백할 수 있지만 명확하게 하는 것이 좋습니다),

따라서 tsconfig 파일에 다음이 있는 경우:

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

package.json 에 이것을 등록해야 합니다.

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

Parziphal 에 2017년 09월 06일

👍17 ❤3

글쎄요 그리고 컨텍스트를 추가하기 위해 "경로"는 Node.js require()와 달리 재매핑을 허용하는 로더와 함께 사용하도록 설계되었습니다. 의도된 동작은 TypeScript가 모듈 ID를 다시 쓰는 것이 아니라 다양한 로더에서 사용하는 다양한 모듈 ID에 대한 유형 정보를 확인할 수 있도록 하는 것입니다. 기본적으로 그것은 당신이 생각한 대로 하지 않습니다. 제 생각에는 로더의 해결 전략을 미러링할 수 있는 기능만 있어야 합니다.

큰 프로젝트에서 설정하려고 시간을 낭비한 후 여기에 왔습니다.
이 동작이 변경되지 않을 경우 이 문제를 종료하기 전에 문서를 업데이트할 수 있습니다.
공식 문서 https://www.typescriptlang.org/docs/handbook/module-resolution.html#path -mapping%20docs 에는 "재매핑을 허용하는 로더"를 사용해야 한다는 내용이 없습니다.

jbgraug 에 2017년 12월 12일

👍26

프로젝트 폴더에 "tspath"를 설치하고 실행하십시오... https://www.npmjs.com/package/tspath

duffman 에 2018년 01월 14일

👍3 👎2

@ef-carbon/tspm

mattyclarkson 에 2018년 02월 06일

👍3 ❤1

또한 "momothepug/tsmodule-alias"를 시도하여 경로 확인의 별칭을 지정할 수 있습니다.

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

DanyelMorales 에 2018년 02월 22일

https://www.npmjs.com/package/module-alias 만 저에게 효과적이었습니다 ...

BorntraegerMarc 에 2018년 05월 01일

나도 tsconfig.json과 package.json 내에서 내 별칭을 추적해야 하는 단점이 있지만 모듈 별칭으로 이 작업을 수행할 수 있었습니다. 누구든지 더 간단한 솔루션을 찾았습니까?

@mattyclarkson 이 지적한 솔루션도 작동하지만 ts-node와 나란히 사용하는 방법을 찾을 수 없습니다. 어떤 아이디어?

edufschmidt 에 2018년 05월 31일

👍1

https://github.com/momoThePug/tsmodule-alias 를 살펴보십시오.

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

나도 모듈 별칭으로 이것을 작동하도록 관리했지만 단점이 있습니다.
tsconfig.json 내에서 내 별칭을 추적해야 하고
패키지.json. 누구든지 더 간단한 솔루션을 찾았습니까?
@mattyclarkson이 지적한 솔루션
https://github.com/mattyclarkson 도 작동하지만 방법을 찾을 수 없습니다
ts-node와 함께 사용합니다. 어떤 아이디어?
—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393662306 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ACKT9JWIkb0Wekz0H_Z3zKXvoE-49EIBks5t4EzkgaJpZM4J6vZQ
.

DanyelMorales 에 2018년 05월 31일

👍2

@DanyelMorales 감사합니다. 이것은 정말 편리합니다.

edufschmidt 에 2018년 05월 31일

천만에요! :)

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

감사 합니다 @DanyelMorales https://github.com/DanyelMorales , 이것은 정말
능숙한.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393688075 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ACKT9GNo30wNv4ZWzSwm_Lv4vesLPI3xks5t4GIzgaJpZM4J6vZQ
.

DanyelMorales 에 2018년 06월 01일

robertmain 에 2018년 06월 27일

👍100 ❤20 😄16 🎉15 😕10

모듈이 아닌 것, 즉 가져오기가 아닌 것에 대해 상대 경로 매핑을 어떻게 해야 합니까?

내가 했던 소스 파일과 관련된 특정 디렉토리를 읽는 노드 스크립트에서:

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

typescript는 스크립트를 컴파일하고 다른 디렉토리(구성 기반)에 쓰기 때문에 __dirname은 더 이상 위의 경로를 해석하지 않습니다. 이에 대한 해결책은 무엇입니까?

tommedema 에 2018년 07월 12일

모듈이 아닌 것, 즉 가져오기가 아닌 것에 대해 상대 경로 매핑을 어떻게 해야 합니까?

그것은 실제로 "Node.js 및 TypeScript 질문을 어떻게 사용합니까?"이며 Gitter.im 또는 StackOverflow에서 훨씬 더 잘 묻습니다.

kitsonk 에 2018년 07월 12일

TypeScript를 좋아하지만 이것은 미친 짓입니다.

timkendall 에 2018년 08월 10일

👍72

나는 그것을 이해하지 못한다. TS 코드베이스에 대해 거의 알지 못하더라도 구현하는 것은 어렵지 않습니다. 방금 클라이언트 및 서버와 공유 프로젝트를 사용하기 시작했습니다... TS가 처음에 경로 기능을 제공한 다음 실제로 사용하기 위해 여러 단계를 거치게 만드는 이유는 무엇입니까? TS에서 내가 만드는 모든 프로젝트에 번들러/로더를 사용하고 싶다고 가정하는 이유는 무엇입니까? 90% 구현된 TS 기능을 보완하기 위해 더 많은 도구 라이브러리를 추가하지 않고 TS를 사용하여 프로젝트를 단순화하려고 합니다.

jpike88 에 2018년 09월 20일

👍7

동의합니다. 내 생각에 TS는 웹팩 때문에 프론트엔드용으로 개발되었습니다.
이미 ts 별칭 경로를 잘 구현하고 있으며 Requirejs도
똑같은 것. 그러나 Nodejs 프로젝트의 경우 너무 어렵습니다. :(

엘 jue., 9월 20일 2018년 02시 50분, Josh Pike [email protected]
기록:

나는 그것을 이해하지 못한다. TS 코드베이스에 대해 거의 알지 못하더라도 이것은
구현하기가 어렵지 않아야 합니다. 공유 프로젝트를 사용하기 시작했습니다.
클라이언트 및 서버와 함께 ... TS가 경로 기능을 제공하는 이유
첫 번째 장소, 그렇다면 실제로 사용하기 위해 농구를 뛰어 넘게합니까? 왜
TS는 내가 모든 프로젝트에 번들러/로더를 사용하기를 원한다고 가정합니까?
만들다? TS를 사용하여 더 많은 작업을 수행하지 않고 프로젝트를 단순화하려고 합니다.
90% 구현된 TS 기능을 보완하기 위한 도구 라이브러리.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-423077950 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ACKT9DD_z4KOHpfwddTomMXujEsza9tQks5uc0jbgaJpZM4J6vZQ
.

DanyelMorales 에 2018년 09월 20일

👍1

+1!

squidfunk 에 2018년 09월 20일

👎1 👍1

webpack은 경로 맵(또는 babel-plugin-module-resolver 과 같은 다른 도구)을 해결하는 데 도움이 될 수 있지만 선언( .d.ts )은 해결하지 못합니다.

선언의 모든 경로가 확인되지 않습니다.

gluons 에 2018년 09월 24일

이 문제에도 부딪쳤습니다. 내보낸 코드에 경로 매핑이 포함된다는 것이 논리적으로 보였습니다. module-alias 에 의존합니다. 그러나 Typescript가 이 기능을 선택적으로 제공하려면 +1입니다.

anthonynovatsis 에 2018년 09월 25일

이것을 컴파일러 옵션으로 추가할 수 없습니까? 분명히 인기 있는 요청입니다. 컴파일러의 작동에 대해 아무것도 모르고 구현하는 것은 매우 간단하지 않습니까? TypeScript 컴파일러로 직접 쉽게 해결할 수 있는데 가장 적절한 곳에서 우리를 다른 곳으로 건너뛰도록 강요하는 이유는 무엇입니까?

MrXyfir 에 2018년 10월 02일

👍26 ❤9

chrisgreeffpp 에 2018년 10월 02일

ts-transformer-imports 및 ttypescript 를 사용하여 절대 및 경로 기반 TypeScript 가져오기를 상대 Javascript 파일로 컴파일할 수 있습니다.

grrowl 에 2018년 10월 05일

tsc 를 계속 사용할 수 있는 컴파일 타임 솔루션을 만들었습니다. https://github.com/joonhocho/tscpaths

Microsoft/TypeScript#15479(주석)

joonhocho 에 2018년 10월 08일

👍2

import {foo} from "@/some/folder/foo" 가 많고 출력된 d.ts 파일이 별칭을 해결하지 못하는 d.ts 파일을 출력하기 위해 vue-cli를 가져오려고 할 때 이 문제가 발생했습니다.

일반적인 검색 및 이 스레드 및 기타 스레드를 살펴보면 무릎 경련 반응이 "TS가 해결할 문제가 아닙니다"인 것처럼 보이지만 사용자 지정 경로 별칭(완전히 유효하고 복잡한 프로젝트에 권장되는 접근 방식) d.ts 파일 생성(사용자 지정 타사 빌드 프로세스 없이)을 사용할 수 없으므로 typescript 컴파일러는 선언 파일 프로세스에서도 이러한 별칭을 해결해야 한다고 말하고 싶습니다.

컴파일러 작업은 typescript 파일에 대해 유효한 javascript 및 d.ts 파일을 출력하는 것이며, 이 유효한 시나리오에서는 단순히 작동하지 않습니다(tsconfig 파일에서 경로 별칭 사용).

grofit 에 2018년 10월 12일

나는 이 문제에 대해 약간 혼란스럽다. 폐쇄되었으며 '의도한 대로 작업 중'이라는 레이블이 지정되었습니다. Typescript가 잘못된 소스를 출력하기 위한 것임을 이해해야 합니까? 이상한 것 같다.

거지는 선택자가 될 수 없지만 Typescript를 사용하면 바닐라 JS의 많은 실망스러운 측면을 피할 수 있으며 상대 가져오기('../../../../../utils/parser')를 그 중 하나로 계산합니다. Typescript가 이것들을 정리할 수 있다면 정말 좋을 것입니다!

codyfyi 에 2018년 10월 14일

👍32

@codeitcody 그런 것 같습니다. 타사 패키지 없이는 작동하지 않는 것을 출력한다는 것은 어리석은 일이지만 그것이 현실입니다.

MrXyfir 에 2018년 10월 14일

👍6 ❤5 😄4

글쎄요, 이것은 좋은 문제가 아닙니까?

본질적으로 후프를 건너 뛰지 않고 앱을 사용할 수 없게 만드는 기능을 갖는 것은 매우 비생산적인 것 같습니다(즉, 문제를 해결하기 위해 더 많은 종속성을 설치).

o8e 에 2018년 11월 01일

👍4

이 문제는 2년 동안 주변에 있었고 구현 여부에 대한 공식적인 언급이 없습니다.

이것이 Node.js 프로젝트에서 TypeScript의 가장 좋은 기능 중 하나를 사용하는 데 필요한 기본 기능임을 고려할 때, 이것이 어떻게 취급되고 있는지 정말 끔찍합니다.

dwjft 에 2018년 11월 02일

👍13

@mhegazy 지금 2년 후에 TypeScript 팀이 이것을 다시 살펴보고 재고할 수 있는지 알려주실 수 있습니까?

MrXyfir 에 2018년 11월 02일

👍23

webpack은 경로 맵(또는 babel-plugin-module-resolver 과 같은 다른 도구)을 해결하는 데 도움이 될 수 있지만 선언( .d.ts )은 해결하지 못합니다.
선언의 모든 경로가 확인되지 않습니다.

이것을 달성하는 방법이 있습니까? 사용자 지정 반응 구성 요소 라이브러리가 있고 별칭에 paths 를 사용하려고 할 때 이 오류가 발생했습니다. 롤업으로 2개의 번들을 수행하고 --emitDeclarationOnly 로 유형을 수행합니다.

다음과 같이 표시되기 때문에 module-alias 를 사용할 수 없습니다.

경고: 이 모듈은 기본 요구 동작을 수정하므로 다른 npm 모듈에서 사용하면 안 됩니다!

poteirard 에 2018년 11월 16일

Reddit: https://www.reddit.com/r/typescript/comments/a07jlr/path_maps_cannot_be_resolved_by_tsc_works_as/ 에서 이 게시물을 찬성하는 데 도움을 주세요.
여기에서 이 엄청난 토론이 필요한 이유를 모르겠습니다. 이 버그를 쉽게 해결할 수 있어야 합니다. tsconfig의 옵션과 모든 사람은 그가 원하는 것이 현재 동작(어떤 이유로든)인지 아니면 작동 방식인지 결정할 수 있습니다.

MikeMitterer 에 2018년 11월 25일

👍4

Dropbox에서도 같은 문제가 있었고 이 변환기를 오픈 소스로 제공했습니다. https://github.com/dropbox/ts-transform-import-path-rewrite

longlho 에 2018년 12월 02일

👍8 🎉2

지금은 같은 경험을 여러 번 했습니다. 경로 별칭이 해결될 것으로 예상하지만 module-alias를 설치하고 package.json을 업데이트하고 기본 파일로 가져와야 한다는 사실을 계속 잊고 있습니다. 이것이 Typescript에 의해 컴파일 단계에서 처리된다면 굉장할 것입니다.

bobmoff 에 2018년 12월 19일

아야. 이것은 TypeScript에 대한 진정한 타격입니다. 이것에 의미가 어디에 있습니까?

ps +1 댓글만 달면 안되나요?

ghost 에 2019년 01월 06일

클럽 @def14nt에 오신 것을 환영합니다. 우리는 TypeScript가 우리의 삶을 더 쉽게 만들기 위해 간단하고 합리적인 컴파일러 옵션을 구현할 날을 참을성 있게 기다리며 더 나은 미래를 바라보며 별이 빛나는 눈을 가진 행복한 몽상가 그룹입니다. 마침내 그 날이 오면 새로 찾은 날개를 타고 장엄하게 석양 속으로 날아가는 돼지의 뽀얀 분홍색 몸을 하늘에서 확인하십시오.

MrXyfir 에 2019년 01월 06일

😄3 ❤2 👍2

Lol, TypeScript 팀이 지원을 추가할 수 있는 것에 대해 npm 확장을 설치하겠습니다. 아마도 그들은 점점 더 많은 개선 사항을 추가하는 것을 중단하고 기본적인 기능을 추가해야 할 것입니다.

ghost 에 2019년 01월 06일

@mika-fischer
https://www.npmjs.com/package/module-alias 를 사용하여 eslint가 '확인되지 않은 경로 '@root/bla/bla'(JS 파일에서)에 대해 경고하도록 중지하는 방법은 무엇입니까? WebStorm 및 VS Code에서 이러한 경로에 대해 자동 완성을 활성화하는 방법은 무엇입니까?

Dzenly 에 2019년 01월 08일

저에게 자동 완성 가져오기는 기본적으로 typescript 프로젝트의 VSCode에서 작동합니다.

bobmoff 에 2019년 01월 08일

@bobmoff 예, TS 파일에서 TS 파일을 가져오는 데 모든 것이 좋은 것 같습니다.
그러나 TS 파일에서 `require('@root/bla/bla')에 대한 자동 완성 및 탐색이 작동하지 않습니다.

내 JS 프로젝트를 TS로 번역하고 싶고 js 파일의 이름을 ts로 하나씩 바꿀 수 있다고 생각했습니다.
이제 나는 그것이 너무 어렵고 ts나 IDE에서 지원하지 않는다는 것을 깨달았습니다. 모든 js 파일의 이름을 한 번에 ts로 바꿔야 합니다.

하나의 JS 파일 이름을 TS로 바꾸면 build 디렉토리의 모든 상대 경로가 손상되기 때문에(아마도 "allowJs: true"를 사용해야 하지만 2GB의 JS 파일이 있는 하나의 프로젝트가 있으므로 그렇습니다. 빌드 디렉토리로 컴파일하는 것이 이상합니다 %)).
좋아, 모듈 별칭으로 이 문제를 해결하려고 하고 내 IDE의 탐색 및 자동 완성이 작동을 멈추고 eslint는 100500 '확인되지 않은 경로'에 대해 경고합니다. 나는 이미 TS를 약간 싫어합니다. TS 마케팅 사람들이 말하는 것처럼 큰 JS 프로젝트를 위한 마이그레이션은 쉽지 않은 것 같습니다. JS 백엔드 프로젝트를 golang으로 마이그레이션하는 것이 더 간단한 것 같습니다. :)

Dzenly 에 2019년 01월 08일

해결 방법으로 tscpaths 를 성공적으로 사용하고 있습니다.

squidfunk 에 2019년 01월 08일

나도. 나는 정말로 tscpaths 를 추천한다. 그것은 예상대로 작동합니다.

michjoh 에 2019년 01월 08일

내 간단한 해결 방법:

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

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

benjamin658 에 2019년 01월 10일

이것을 우연히 발견했는데 때로는 TypeScript가 정말 골치 아픈 일이 될 수 있습니다.

fabiospampinato 에 2019년 01월 13일

왜 이 스레드가 계속해서 계속되고 있는지 이해가 되지 않습니다.
우리는 모두 "경로 지옥"에 대해 알고 있으며 (별칭을 사용하여)
정말 깨끗하다
그 혼란까지, 이 스레드의 모든 사람들이 이것을 알고 있습니다!

별칭은 TypeScript 컴파일러에 의해 해석되며 정확히 컴파일됩니다.
그래야 하듯이,
결과 자바 스크립트에서 주변을 찌르지 않아야합니다.
당신은 사용하고 싶어
별칭은 스스로 해결해야 합니다!

....또는 Apple, Google 및 Microsoft에서 스레드 시작
JavaScript 엔진에서 기능을 구현하도록 요청하여
그들은 할 수있다
당신의 별칭을 interpet ;-)

TypeScript 컴파일러는 정확히 해야 할 일을 합니다!

Angular 세계에서 작업하는 경우 도로가 포장되어 있고 원하는 경우
당신의
Node에서 직접 코드를 작성하려면 경로를 해결하는 도구가 필요합니다.
만들어진
당신을 위한 그런 도구는 지금 1년 넘게 생산에 사용되었습니다.
이다
여기 스웨덴에서 가장 큰 신문에서 사용하는, 나는 이것을 당신이 할 수 있도록 만들었습니다
맨발로 가다
Node와 함께 뼈, 나는 여기에서 아무것도 팔려고하지 않습니다, 나는 돈을 벌지 않습니다
이것으로부터 :)

예, "tsmodule-alias" 및 유사한 해킹 도구가 있습니다.
실제로 작동시키다
매우 조심하지만 엉망인 경우 다음을 사용하는 해결 방법이 있습니다.
ts 노드,
쉘 스크립트 등...야다야다

드디어 충분하다고 느껴서 스스로를 가두고 만들었어요.
TsPath
컴파일 시간 별칭

> npm 설치 -g tspatj

myproject> tsc

myproject> tspath

또는

myproject> tspath --f

헤드리스(빌드 서버에서 매우 유용함)

그런 다음 완료되었습니다. 이제 JavaScript 파일에
올바른 상대 경로, 이것이 우리가 여기서 원하는 것이 아닙니까?

건배! :)

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

덴 손 1월 13일 2019 kl 22:20 skrev Fabio Spampinato <
알림@github.com>:

이것을 우연히 발견했는데 때로는 TypeScript가
나귀.
—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-453866553 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAy_7JYrwYo3KOLxpLWP0np5JVz2kQzks5vC6MogaJpZM4J6vZQ
.

duffman 에 2019년 01월 14일

😕4 👎4

@duffman

별칭은 TypeScript 컴파일러에 의해 해석되며 정확히 컴파일됩니다.
그래야 하듯이 결과 자바 스크립트에서 주변을 찌르지 않아야합니다.
별칭을 사용하려면 이 문제를 스스로 해결해야 합니다!

매우 동의하지 않습니다. 당신이 농담을 하지 않는 한, 나는 정말로 말할 수 없었습니다.

TypeScript는 네이티브 컴파일러에 부분적으로만 구현된 작업을 완료하기 위해 타사 도구 없이 _작동_하는 코드를 컴파일해야 합니다.

MrXyfir 에 2019년 01월 14일

👍9

TypeScript 컴파일러는 정확히 해야 할 일을 합니다!

이 스레드가 tsc 도 축소 또는 이와 유사한 작업을 수행하도록 요청하는 사람들로 가득 차 있다면 귀하의 의견에 동의합니다. 그러나 그렇지 않습니다. 컴파일러가 실행 가능한 코드를 생성하도록 요청하는 것은 사람들입니다. 컴파일러에게 너무 많은 것을 요구하는 것은 아니라고 생각합니다. 그렇지 않나요?

robertmain 에 2019년 01월 14일

👍5

그리고 다음과 같은 기능을 사용하지 않으면 실행 가능한 코드를 생성합니다.
JavaScript 엔진에서 지원하지 않는 것은 많은 의미가 있습니다.
예를 들어: 애플리케이션이 다음과 같은 경우 C++ 컴파일러를 비난하시겠습니까?
동적 링크 라이브러리를 사용하고 프로그램이 컴퓨터에서 실행되지 않음
이것들이 설치되어 있지 않습니까?

상대경로를 관리하면 활용할 수 있는 기능이며,
Angular가 WebPack에서 하는 것처럼 또는 내가 하듯이 책임을 져야 합니다.
TSPath가 있는 모든 TypeScript 프로젝트!

작업 환경을 설정하는 방법을 이해하지 못하면 사용하지 마십시오.
여기에서 이것이 Microsoft의 책임이라고 생각하지 않습니다.
기능을 제공했으며 작동 방식은 다음과 같습니다.
원하는 대로 작동하지 않거나 작동할 것으로 예상할 수 있지만 그렇게 하지 않습니다.
틀렸어!

또한, 나는 당신이 진지하게 이것이 당신을 방해하도록하고 있는지 궁금합니다.
TypeScript를 사용하여 개발하시겠습니까?

1월 14일 덴 2019 kl 21:34 skrev 로버트 메인 알림 @github.com :

TypeScript 컴파일러는 정확히 해야 할 일을 합니다!
이 스레드가 tsc도 수행하도록 요청하는 사람들로 가득 차 있다면
축소 또는 이와 같은 것, 나는 당신에게 동의할 것입니다. 그러나 그렇지 않습니다. 이것의
컴파일러가 실행 가능한 코드를 생성하도록 요청하는 사람들. 나는 정말
컴파일러에게 너무 많은 것을 요구한다고 생각하지 않습니까?
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454151277 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAy_7FeuOJanI9bXYSVgf_YghJluTyGks5vDOnEgaJpZM4J6vZQ
.

duffman 에 2019년 01월 15일

이것은 상대 경로를 관리하고 Angular가 WebPack을 사용하는 것처럼 또는 내가 TSPath를 사용하는 모든 TypeScript 프로젝트에서 하는 것처럼 상대 경로에 대한 책임을 지는 경우 활용할 수 있는 기능입니다!

이것은 컴파일러가 깨진 코드를 출력하게 하는 기능입니다. 해당 경로를 적절하게 해결하기 위해 한 줄의 코드만 작성하면 작동할 수 있는 코드입니다.

TS가 출력된 코드를 실행하기 위해 외부 번들러가 필요하다는 사실은 너무나 당연합니다.

fabiospampinato 에 2019년 01월 15일

👍5

그리고 다음과 같은 기능을 사용하지 않으면 실행 가능한 코드를 생성합니다.
JavaScript 엔진에서 지원하지 않음,

저는 항상 TypeScript가 JavaScript로 컴파일되어야 한다는 것을 이해했습니다. 특정 기능이 JavaScript 엔진에서 지원되지 않는다고 말하면 정확히 왜 거기에 있습니까?

응용 프로그램 동적 링크 라이브러리와 프로그램이 머신에서 실행되지 않는 프로그램이 설치되어 있지 않다면 C++ 컴파일러를 비난하시겠습니까?

아니요, 하지만 컴파일러 오류나 경고 없이 실제로 존재하지 않는 다른 C++ 코드에 링크할 수 있게 해준다면 비난할 것입니다.

robertmain 에 2019년 01월 15일

정말 이해가 안 되시죠? 코드가 깨지지 않은 경우
컴파일러를 구성했기 때문에 깨진 것입니다.
이 경우 "플랫폼"이 지원하지 않는 코드를 생성하려면
별칭!

귀하의 경우 별칭을 사용하지 마십시오. "당신"은 별칭을 지원하지 않습니다. 진지하게!

이것이 1줄 수정이더라도(물론 그렇지는 않음)
컴파일러가 무엇을 해야 하는지와
하지 말아야 한다! 이 기능은 로더를 지원하지 않기 위해 추가되었습니다.
반대로 읽다
공식 문서의 경로 매핑에 있으므로 다시 사용하고 있습니다.
잘못된!

다시 말하지만, 이 기능은 Loaders/Resolvers를 위한 것입니다.
작동하므로 Microsoft
별칭 없이 붙여넣을 수 있도록 컴파일러를 변경해서는 안 됩니다.
지원하는 환경!

덴티스 1월 15일 2019 kl 04:41 skrev Fabio Spampinato <
알림@github.com>:

상대경로를 관리하면 활용할 수 있는 기능이며,
Angular가 WebPack에서 하는 것처럼 또는 내가 하듯이 책임을 져야 합니다.
TSPath가 있는 모든 TypeScript 프로젝트!
이것은 컴파일러가 깨진 코드를 출력하도록 하는 기능입니다.
문제를 해결하기 위해 한 줄의 코드만 작성하면 작동할 수 있습니다.
경로.
TS는 출력된 코드가
실행될 수 있다는 것은 매우 어리석은 일입니다.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454256799 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAy_zuWKV0qzzWt6_jZNgDLFt1TA0tMks5vDU3vgaJpZM4J6vZQ
.

duffman 에 2019년 01월 15일

👎5

로더가 경로 매핑을 사용하기 때문에 존재하므로 지원됩니다!
그리고 당신이 (나처럼) 로더 없이 그것들을 사용하라고 주장하기 때문에,
문제
기능을 사용할 수 있도록 도구를 사용하시겠습니까?

덴티스 1월 15일 2019 kl 05:10 skrev 로버트 메인 알림 @github.com :

그리고 다음과 같은 기능을 사용하지 않으면 실행 가능한 코드를 생성합니다.
JavaScript 엔진에서 지원하지 않음,
나는 항상 TypeScript가 다음으로 컴파일되어야 한다는 것을 이해했습니다.
자바스크립트. 특정 기능이 지원되지 않는다고 말하면
JavaScript 엔진이 정확히 왜 거기에 있습니까?
응용 프로그램 동적 링크가 있는 경우 C++ 컴파일러를 비난하시겠습니까?
라이브러리와 프로그램이 머신에서 실행되지 않는다는 것은
설치?
아니요, 하지만 그렇지 않은 다른 C++ 코드에 연결할 수 있게 해준다면 비난할 것입니다.
실제로 컴파일러 오류나 경고 없이 존재합니다.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454260977 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAy_25-ZmS235i1Ic7mvSzEt2QJDX6Bks5vDVTAgaJpZM4J6vZQ
.

duffman 에 2019년 01월 15일

이봐, 난 당신의 요점을 참조하십시오. 그렇다. 그러나 컴파일러 작업의 일부는 마지막으로 한 번 제대로 확인하는 것입니다. 기껏해야 컴파일되지만 실행되지 않는 코드는 일관되지 않은 동작이며 이 문제를 처음 읽었을 때 문서에서 분명히 존재하지 않는 동작을 제안하는 것처럼 보였습니다.

robertmain 에 2019년 01월 15일

문서의 해당 섹션을 알려주세요.

1월 15일. 2019 클. 05:31 skrev 로버트 메인 알림 @github.com :

이봐, 난 당신의 요점을 참조하십시오. 그렇다. 그러나 컴파일러 작업의 일부는 온전한
마지막으로 한 번만 확인하십시오. 컴파일되지만 실행되지 않는 최상의 코드는
일관성 없는 행동과 내가 이 문제를 처음 읽었을 때
문서는 분명히 존재하지 않는 행동을 제안하는 것 같았습니다.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454263854 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAy_8e5v8IV-ynmjRTeoC3cp5llwnsIks5vDVm8gaJpZM4J6vZQ
.

duffman 에 2019년 01월 15일

이 기능은 로더를 지원하지 않기 위해 추가되었습니다.
반대로 읽다
공식 문서의 경로 매핑에 있으므로 다시 사용하고 있습니다.
잘못된!

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

sukovec 에 2019년 01월 15일

👍4

@duffman 여기 사람들이 이 기능을 원한다는 것이 보이지 않습니까??? 이 "기능"을 어떻게 사용해야 하는지 이해하기에는 너무 어리석다고 모든 사람에게 말하고 있습니다. 좋아 - 그렇게 볼 수는 있지만 누가 알겠습니까? 아마도 반대일 것입니다...

MikeMitterer 에 2019년 01월 15일

그건 그렇고, 내 의견은 다음과 같습니다.

별칭은 컴파일러에 내장되어 있고 프로젝트를 컴파일하는 것은 괜찮습니다. 그것은 사용자가 그것이 제안하는 방식으로 작동한다고 생각하게 할 수 있습니다(이 문제는 내가 옳다는 꽤 좋은 증거입니다). 비논리적으로 보이기도 합니다. "공식" 편집기(vscode - 특히 "자동 가져오기" 기능을 사용하는 경우 vscode는 별칭 경로를 사용)에서 작동하는 이유는 무엇이며, 결과 코드가 작동하지 않을 때 컴파일러도 정상적으로 작동하는 이유는 무엇입니까? "js 엔진이 지원하지 않습니다"라고 말하면 더 묻고 싶습니다. TS는 일부 JS "문제"를 완화하기 위한 것이 아니었나요?

나는 이것에 대한 두 가지 해결책 중 하나를 기대합니다.
1) 별칭으로 가져오기를 올바르게 재정의
2) 경고 표시

"올바른 행동"이라고 말하는 것은 잘못된 것이라고 생각합니다. 그렇지 않다. TS는 어셈블리 언어가 아니며 C/C++도 아닙니다.

sukovec 에 2019년 01월 15일

👍1

개발 팀은 별칭 확인에 대한 지원을 추가해야 합니다. 추가하는 것이 좋습니다
tsconfig의 컴파일러 확인을 위한 키입니다.

마이크로소프트가 좋다!!!!!!

별칭이 있는 응용 프로그램을 개선하려면 여러분의 도움이 필요합니다.

:( 여기 있는 모든 사람들은
일관성. Typescript는 굉장합니다, 나는 그것을 좋아합니다...

우리는 그것을 사랑합니다!

노숙자 개발자 안부...

El mar., 15 de ene. 2019년 08:02, Mike S. [email protected]
기록:

그건 그렇고, 내 의견은 다음과 같습니다.
별칭은 컴파일러에 내장되어 있으며 컴파일은 괜찮습니다. 그것은 사용자를 만들 수 있습니다
그들이 생각하는 대로 작동해야 한다고 생각합니다(이 문제는
그것이 사실이라는 좋은 증거). 비논리적 인 것 같습니다. 왜 무언가가 작동합니까?
"공식" 편집기(vscode - 특히 "자동 가져오기" 기능을 사용할 때,
vscode는 별칭 경로를 사용함), 결과 코드에서 컴파일러도 정상적으로 작동하는 이유
작동하지 않는다? "js 엔진이 지원하지 않습니다"라고 말하면 묻고 싶습니다.
더 나아가 - TS는 JS "문제" 중 일부를 완화하기 위한 것이 아니었나요?
나는 이것에 대한 두 가지 해결책 중 하나를 기대합니다.
별칭으로 가져오기를 올바르게 재정의
경고 표시
"올바른 행동"이라고 말하는 것은 잘못된 것이라고 생각합니다. 그렇지 않다. TS는 아니다
C/C++도 아닌 어셈블리 언어.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454384357 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ACKT9OqexgOaHH1vDFuRcO7U_r2DEC23ks5vDdFbgaJpZM4J6vZQ
.

DanyelMorales 에 2019년 01월 15일

👍1

. TS는 어셈블리 언어가 아니며 C/C++도 아닙니다.

TS가 C++가 아니라는 점을 확인하여 지적하려는 내용을 정말 이해하지 못합니다. 우리 대부분은 그 점을 잘 알고 있다고 생각합니다!

우리는 또한 별칭/경로 매핑이 전 세계의 프로덕션에서 사용된다는 사실을 확인했습니다. 따라서 VS Code는 당연히 이를 지원해야 하지만 설정에 맞게 컴파일러를 만드는 것은 여전히 MS가 주장하는 바가 아닙니다!

내가 이해하는 데 어려움을 겪고 있는 것은 왜 계속 사용하는지, 컴파일러는 작동해야 하는 대로 작동하는지, 다시 한 번 기능이 무엇을 위한 것인지 명확하게 설명하는 문서를 읽으십시오!

내 말은 2분 안에 경로 별칭으로 작동하는 TS 개발 환경을 설정할 수 있다는 뜻입니다. WebPack을 사용하지 않으려면 TSPath를 사용하여 1초 안에 모든 js 파일의 모든 경로를 확인하고 패키지에 추가할 수 있습니다. .json을 실행 스크립트로 사용하고 그것에 대해 생각할 필요도 없습니다. 문제가 존재하지 않습니다. 컴파일러는 원래대로 작동하며 계속해서 행복한 만세를 보낼 수 있습니다!?

또는 실제 컴파일러가 이 작업을 수행하는 것이 매우 중요하다면 컴파일러를 분기하여 직접 구현하는 것이 좋습니다. 아마도 큰 성공을 거두거나 사람들이 설정한 이후로 있는 그대로 행복할 것입니다. 별칭을 지원하는 환경.

duffman 에 2019년 01월 15일

❤1 😕1 👍1

TypeScript 기여자 상위 5명 소환: @ahejlsberg @andy-ms @DanielRosenwasser @sandersn @sheetalkamat

TypeScript 팀이 이 문제를 재고할 수 있습니까? 나는 이 스레드가 두 가지 관점에 대한 유용한 토론을 제공하고 최근의 인기와 시간이 지남에 따라 다시 살펴봐야 한다고 생각합니다.

MrXyfir 에 2019년 01월 15일

👍19 ❤5 🎉4 👎1

이 문제의 상태는 TS를 유형 검사기 의무로만 강등하는 것 외에 다른 선택의 여지가 없었습니다.
Babel은 이제 TS 구문에 대한 적절한 지원을 제공하며 babel-plugin-module-resolver 와 함께 이 사용 사례에 대한 작업 코드를 내보내는 작업을 잘 수행합니다.
유일한 단점은 Babel이 TS 구성에 신경 쓰지 않기 때문에 tsconfig.json 에서 구성 비트를 복제한다는 것입니다. 그러나 노드 프로젝트에서 절대 경로를 작업하는 데는 수용 가능한 가격이며 보너스로 babel 매크로와 같은 멋진 기능으로 전체 생태계를 얻습니다.

이것은 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
package.json :
tsc -> tsc && babel ./src --out-dir ./dist --extensions ".ts,.js"
tsconfig.json :

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

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

InvictusMB 에 2019년 01월 22일

👍4

절대 경로가 있는 typescript를 사용하고 싶지만 webpack이나 babel 등을 구성해야 하는 것 같습니다. 이 간단한 기능을 구현하는 것은 너무 어렵습니다. 더 쉬울 것입니다 😞

ywwhack 에 2019년 01월 28일

👍6

이 문제를 인정합니다. 이 특정 사항을 알고 있었는지 확실하지 않습니다.
내 개인 설정으로 인한 문제이거나 아마도 나는 :) 슈퍼가 아닙니다.
무거운 수정, 수정은 단순히 distPath를 (맹목적으로) 신뢰하는 것입니다.
현재 솔루션보다 실제로 점점 더 간단한 코드입니다.
내일까지 수정이 가능하도록 하세요...

덴 월 28일 1월 2019 kl 15:59 skrev 叶伟伟[email protected] :

절대 경로와 함께 typescript를 사용하고 싶지만
config webpack 또는 babel 또는 무언가, 그것은 달성하기가 너무 어렵습니다!!!
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-458164055 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAy_1_T-An7swSND-xdBhL0HNHxQkm6ks5vHxBggaJpZM4J6vZQ
.

duffman 에 2019년 01월 28일

paths 의 현재 동작에 대한 실제 문서화된 사용 사례 가 이 스레드에서 언급되지 않았기 때문에 여기에 남겨둡니다. @types/ 패키지는 semver와 관련된 기능을 백포트하지 않습니다. 그러나 여기에는 내가 사용할 수 있는 이전 API에 대한 업데이트된 유형이 포함됩니다. 예를 들어 history@3 history@2 $#$를 사용하고 있습니다.

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

컴파일러는 유형 별칭과 "코드" 별칭을 구별하기 위해 추가 옵션이 필요합니다. 실제로 경로 별칭을 내보내도록 동작을 변경하면 올바른 유형 버전을 찾는 기능을 컴파일러에 추가해야 합니다.

이것은 제안된 행동에 대한 주장이 아닙니다. 차라리 별칭을 내보내고 유형 버전 관리를 위한 작업 솔루션을 사용하고 싶습니다. 이것을 변경하는 것이 사람들이 생각하는 것만큼 사소하지 않은 이유를 설명하고 싶었습니다.

eps1lon 에 2019년 02월 07일

두 번째로 전사 TS 워크숍에서 이 어리석고 당혹스러운 행동을 설명해야 했습니다...

진지하게!

어떤 종류의 언어 컴파일러, 특히 기본 판매 피치가 JavaScript에 대한 정확성이 더 높은 컴파일러가 "기능"으로 깨진 코드를 생성합니까?!?!

cruhl 에 2019년 02월 14일

👎1

제 댓글에 너무 답답해 보여서 죄송합니다. 하지만 여기 커뮤니티의 견해는 반복적으로 무시되고 경시되고 있는 것 같습니다.

cruhl 에 2019년 02월 14일

이게 몇 번이나 참조되었는지 보세요... 그렇게 많은 사람들에게 시간과 관심을 낭비하는 것입니다.

cruhl 에 2019년 02월 14일

👎1

나는 당신의 좌절을 이해하지만 많은 사람들이 행동이 옳다고 느끼는 것이 그것이 옳은 일이라는 의미는 아닙니다.

TypeScript 재작성 모듈 식별자는 미끄럽고 미끄러운 경사입니다. 이 스레드에서 여러 번 표현된 것은 TypeScript가 대체하거나 구현하지 않고 다른 모듈 해석기 및 기타 빌드 도구의 동작을 모델링하도록 구성할 수 있다는 것입니다.

TypeScript가 모듈을 유연한 방식으로 해결하도록 구성할 수 있다고 해서 TypeScript가 "깨진 코드"를 내보내는 것은 아닙니다. 이 구성을 미러링하는 특정 로더 및 번들러는 제대로 작동합니다.

우리가 어떤 것에 대해 비판적이라면, 우리는 결코 수정할 의도가 없었던 문제를 해결하는 것처럼 보일 수 있는 옵션의 이름을 지정했다고 팀을 비난할 수 있습니다. .

특정 도구가 문제를 해결하지 못한다고 해서 항상 그 도구가 잘못되었다는 의미는 아닙니다. 문제를 해결하는 데 필요한 모든 도구가 없을 수도 있습니다.

kitsonk 에 2019년 02월 14일

👎1 👍1

@kitsonk 당신이 방금 말한 모든 것은 기준에서 벗어났습니다.

문제는 TS가 개발/테스트 중에 한 방향으로 작동하고 컴파일이 완료된 후에 다른 방향으로 작동한다는 것입니다.

TS가 모듈 리졸버가 되려면 패턴을 선택하고 고수해야 합니다. ts-node 로 무언가를 실행하면 마치 TS를 컴파일하고 node 로 실행한 것처럼 정확히 작동해야 합니다.

그렇지 않고 그것이 문제입니다.

dwjft 에 2019년 02월 14일

아마도 모듈 맵은 미래에 좌절감을 덜어줄 것입니다. 그러나 여기서 우리가 해결하고자 하는 기술적 문제와 함께 우리의 입장은 매우 분명합니다. 경로 매핑은 외부 해결 체계의 동작을 반영합니다(예: AMD 및 System.js의 경로 매핑, Webpack 및 기타 번들러의 별칭). 그것은 우리가 당신의 길을 바꿀 것이라는 것을 의미하지 않습니다.

최근 논의가 최근에 건설적이라고 생각하지 않으며 향후 변경 사항도 예상하지 않으므로 이 문제를 잠그겠습니다.

DanielRosenwasser 에 2019년 02월 14일

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Typescript: 방출된 코드에서 모듈 경로 맵이 확인되지 않음

가장 유용한 댓글

모든 76 댓글

> npm 설치 -g tspatj

myproject> tsc

myproject> tspath

myproject> tspath --f

관련 문제