Typescript: 모듈 지정자의 끝에 '.js' 파일 확장자를 추가하는 방법 제공

#13422만의 문제가 아니라 같은 문제입니다. 그러나 중요한 문제라고 생각한다는 사실에도 불구하고 응답은 상당히 부정적이었습니다. 따라서 귀하의 문제가 더 잘 받아들여지기를 바랍니다.

글쎄, 나는 그것이 추가되기를 바랍니다. 우리는 다음 TypeScript 팟캐스트에서 이것을 사용하여 내 POC에 대해 논의하기를 정말로 고대했지만 빌드 도구 없이 TypeScript를 사용하려면 기다려야 할 것 같습니다.

현재 TypeScript는 경로를 다시 작성하지 않습니다. 확실히 짜증나지만 현재 .js 확장자를 직접 추가할 수 있습니다.

@jusinfagnani @rictic

팁 감사합니다. 이를 위해 쉘/노드 스크립트를 작성하겠습니다.

@DanielRosenwasser 레이블 아래에 기본 ES6 모듈 문제를 수집하는 것이 의미가 있습니까?

또한 이 문제를 조금 일반화하기 위해 실제로 .js 확장자를 추가하는 것이 아니라 확장자가 무엇이든 모듈 지정자를 실제 경로로 해결하는 것이라고 생각합니다.

실제로 typescript의 도메인은 아니지만 내 사용 사례에 대한 또 다른 문제를 발견했습니다.

node_modules를 처리하는 방법을 잘 모르겠습니다. 일반적으로 webpack은 ts-loader를 통해 코드에 번들을 제공하지만 분명히 브라우저에서는 이를 이해하지 못합니다.

import { KeyCodes } from 'vanilla-typescript;
https://github.com/quantumjs/vanilla-typescript/blob/master/events/KeyCodes.ts#L3

여기에 js 확장을 추가하는 것은 의미가 없습니다.

서버에서 실행되는 typescript 또는 url resolver에 의한 경로 확장이 있어야 한다고 생각합니다.

나는 그것이 오히려 틈새 케이스에 감사하지만 TS가 이 영역에서 일찍 빛날 수 있는 방법이 될 것이라고 생각합니다. tsc 컴파일러에 대한 플러그인이 될 수 있습니까?

여기에 와서 임시 솔루션을 원하는 사람을 위해 import 문에 js 파일 확장자를 추가하는 스크립트를 작성했습니다.

"use strict";

const FileHound = require('filehound');
const fs = require('fs');
const path = require('path');

const files = FileHound.create()
  .paths(__dirname + '/browserLoading')
  .discard('node_modules')
  .ext('js')
  .find();


files.then((filePaths) => {

  filePaths.forEach((filepath) => {
    fs.readFile(filepath, 'utf8', (err, data) => {


      if (!data.match(/import .* from/g)) {
        return
      }
      let newData = data.replace(/(import .* from\s+['"])(.*)(?=['"])/g, '$1$2.js')
      if (err) throw err;

      console.log(`writing to ${filepath}`)
      fs.writeFile(filepath, newData, function (err) {
        if (err) {
          throw err;
        }
        console.log('complete');
      });
    })

  })
});

이걸 cli 도구로 만들 수 있을지도..

@justinfagnani 님 의 댓글이 머리에 못을 박았습니다.

또한 이 문제를 조금 일반화하기 위해 실제로 .js 확장자를 추가하는 것이 아니라 확장자가 무엇이든 모듈 지정자를 실제 경로로 해결하는 것이라고 생각합니다.

당신이 쓸 때

import { KeyCodes } from 'vanilla-typescript';

또는 그 문제에 대해

import { KeyCodes } from 'vanilla-javascript';

모듈 지정자에서 가져오는 경우 파일일 수도 있고 아닐 수도 있지만 이 경우 끝에 .js 를 추가하면 유효한 해결 결과가 나오지 않을 것입니다.

NodeJS 응용 프로그램을 작성하는 경우 NodeJS Require 알고리즘은 다양한 해석을 시도하지만 추상 이름을 참조하고 규칙과 구성에 따라 해석되기 때문에 'vanilla-typescript.js' 로 해석하려고 시도하지 _않습니다_( 아마도 다양한 시도를 통해) '../../../node_modules/vanilla_typescript/index.js' .

AMD와 같은 다른 환경은 이 해상도를 수행하는 방법에 대해 차이가 있지만 이러한 모든 환경이 공통적으로 가지고 있는 한 가지는 추상화된 모듈 지정자 개념입니다.

다양한 브라우저에서 제공되는 ES 모듈 구현이 불완전한 것을 구현하기 때문에 이 문제를 제기합니다. 가장 단순한 종속성조차도 고려하고 전이적인 종속성에 대한 주제를 다루자 마자 doggone 항목을 구성하는 방법이 필요하다는 것이 분명해집니다.

그것은 먼 이야기일 수 있지만, 당신이 발견하고 있는 것처럼 우리에게 주어진 이 (정중하게) 개념 증명 구현에 쓰는 것은 현실적이지 않습니다.

또한 문제는 환경에 따라 다르기 때문에 TypeScript가 여기에서 어떻게 도움이 될 수 있는지 모르겠습니다.

@QuantumInformation .js 를 경로에 추가하는 프로그램은 멋지고 가볍고 우아해 보이지만 궁극적으로 자신의 모듈 번들러를 구현하고 있습니다. 재미있고 흥미로운 작업이지만 브라우저에서 사용할 수 있는 현재 구현의 결함을 보여줍니다. 순수 JavaScript로 작성하더라도 전이적으로 가져온 종속성을 컴파일하고 패키징하기 위해 여전히 무언가가 필요합니다.

나는 기본적으로 릴리스된 ES 모듈의 구현이 적절하지 않다는 사실에 대해 불평하고 있습니다.

다시 NodeJS, RequireJS AMD, Dojo AMD, Sea Package Manager, CommonJS, Browserify, Webpack, SystemJS는 모두 고유한 작업 방식을 가지고 있지만 모두 추상적인 이름 확인을 제공합니다. _기본_이기 때문에 제공해야 합니다.

제 욕을 읽어주셔서 감사합니다.

어떤 버전의 TS가 추가했는지 확실하지 않지만 ' ./file.js' 와 같은 가져오기가 이제 작동합니다(파일이 실제로 file.ts인 경우에도).
TypeScript는 파일을 잘 해석하고 완전한 .js 가져오기를 대상으로 출력합니다.
lit-html 사용: https://github.com/PolymerLabs/lit-html/blob/master/src/lib/repeat.ts#L15

TS 2.0부터 가능합니다. 그러나 webpack과 같은 도구는 이를 지원하지 않으므로 결국 쓸모가 없습니다.

소스에서 ts-loader를 사용하는 경우에는 쓸모가 없습니다(가장 일반적인 사용 사례).
실제 js 파일이 거기에 있고 해결 프로세스에서 찾을 수 있기 때문에 대상(일반적으로 "dist" 폴더)을 번들로 묶는 것은 여전히 ​​가능합니다.

대상 코드에서 .js 확장을 제거하여 소스에서 직접 번들로 허용하는 빠른 변환을 ts-loader 에서 구현할 수 있는지 궁금합니다.

그렇게 하면 좋을 것입니다. 몇 달 전에 ts-loader와 같은 주요 webpack ts 로더에 문제를 게시했는데 꽤 나쁜 반응을 받았습니다...

참고로 롤업 타입스크립트 플러그인은 가능하다는 증거로 문제가 없습니다.

대부분의 종속성이 올바르게 로드되지 않기 때문에 브라우저 로더 구현 및 WGATWG 로더 사양이 최소한 _일부_ 구성을 지원할 때까지 이것이 무엇을 하는지 알지 못합니다.

내 관점에서는 아직 URL이 아닐 수 있는 임의의 문자열 리터럴 지정자를 참조하는 가져오기에 네이티브 로더를 사용하는 것이 실용적이기 전까지는 이 중 아무 것도 중요하지 않습니다. 실제 URL.

그때까지 우리는 SystemJS 및 Webpack과 같은 도구에 계속 의존할 것입니다.

import/export 문에서 '.js'를 제거하는 작은 변환기를 만들었습니다.
tsutils 유형 가드를 사용했기 때문에 yarn add tsutils --dev . (프로젝트에 tslint 가 있으면 패키지가 일반적으로 설치되므로 추가 종속성이 있음)

https://gist.github.com/AviVahl/40e031bd72c7264890f349020d04130a

이것을 사용하여 .js 로 끝나는 파일에서 가져오기를 포함하는 ts 파일을 묶을 수 있으며( webpack 및 ts-loader 사용), 여전히 소스를 로드할 수 있는 esm 모듈로 트랜스파일할 수 있습니다. 브라우저( tsc 사용).

이것이 유용한 사용 사례는 아마도 제한적일 것입니다.

편집: 내보내기에서도 작동하도록 요점을 업데이트했습니다. 순진하고 최적화되지 않았지만 작동합니다.

이 문제에 대한 움직임이 있습니까?

이 확장 문제는 TypeScript의 맨 처음으로 돌아가 tsconfig.json 가 필요한 이유와 module 옵션이 compilerOptions 설정에 추가된 이유를 설명합니다.

extension 확장의 문제는 ES2015+에 대해서만 문제가 필요하므로 꽤 잘 해결할 수 있으므로 대상 코드가 ES2015+일 때 컴파일러에서 추가하도록 합니다.

1. .js 에 대한 .ts
2. .jsx 에 대한 .tsx

안녕하세요 늦게 왔지만 도움이 되었으면 합니다. 문제가 무엇인지 이해하는 데 문제가 있습니다. OP 예에서 다음과 같습니다.

import { ModalBackground } from './ModalBackground';

'./ModalBackground' 가 무엇인지 모르는 문제입니까? 폴더 또는 다른 것이 될 수 있습니까?

전체 프로젝트에서 tsc 를 실행하고 ModalBackground.ts가 존재한다는 것을 알고 있다면 확장을 추가하는 것이 안전하다는 것을 알 수 있습니다.

이 문제는 또한 RxJS 커뮤니티가 매우 관심을 갖고 있는 문제입니다. 이에 대한 솔루션의 타임라인은 무엇입니까? 심지어 우선 순위가 있습니까? 도움이 될 타사 변환이 있습니까?

출력 대상이 ES2015인 경우 이것이 문제인지 확실하지 않습니다. 이것은 ES2015browser 기능의 영역에 속할 수 있습니다. 더군다나 @justinfagnani 가 이것을 플랫폼 목표로 추진할 수는 없나요? (별도의 스레드로 분기해야 할 수도 있음).

더군다나 @justinfagnani 가 이것을 플랫폼 목표로 추진할 수는 없나요? (별도의 스레드로 분기해야 할 수도 있음).

네, 물론 많은 사람들이 플랫폼이 어떤 형태의 베어 지정자를 지원하기를 원하지만 현재 사실은 그렇지 않으며 추가할 제안조차 없다는 것입니다. 우리는 그 전체, 아마도 다년 과정을 거쳐야 합니다.

궁극적으로 지정자만 지원한다고 해도 노드-모듈-해상도가 있는 그대로의 형태가 될 가능성은 매우 낮습니다. 따라서 tsc에서 파일을 찾는 데 사용하는 해상도 알고리즘과 브라우저에서 사용하는 해상도 알고리즘(노드의 기본 모듈 지원인 afaik) 간에 불일치가 발생합니다.

다운스트림 도구와 환경이 충돌하는 의견으로 지정자를 해석하지 않도록 tsc가 다른 모듈을 찾는 데 사용한 경로를 구체화할 수 있다면 좋을 것입니다.

@justinfagnani 그들은 이미 상충되는 의견으로 해석됩니다. TS는 생성하는 JS 코드가 가리키지 않는 JS 파일을 생성합니다. ES6은 JavaScript를 수행하는 공식적으로 올바른 방법에 가장 가까운 것이므로 TypesScript에서 생성한 ES6 코드가 잘못된 경우 이는 단순하고 단순한 버그입니다. 제안 등을 기다릴 필요가 없습니다. TypeScript의 버그를 수정하기만 하면 됩니다. 하지만 오늘날 사람들은 무언가 잘못을 찾지 않고 10단계의 제안을 거쳐 연기를 하면 지적으로 행동하지 않는다고 생각합니다. 쉬게 해줘

@aluanhaddad 많은 프로젝트가 혜택을 받지 못하는 것은 사실이지만 npm 종속성을 사용하지 않는(또는 어떤 식으로든 npm 종속성을 처리할 수 있는) 일부 프로젝트가 있으므로 해당 프로젝트가 도움이 될 것입니다.

ES6으로 컴파일된 TypeScript 라이브러리 에도 매우 유용합니다. 현재 이러한 라이브러리는 브라우저에서 기본적으로 사용할 수 없지만 TypeScript가 .js 확장을 출력하면 작동합니다.

@justinfagnani 아직 표준화되거나 구현되지 않았지만 브라우저에서 npm 패키지가 작동하도록 하는 제안이 있습니다.

패키지 이름 맵은 TypeScript 컴파일러나 다른 도구에 의해 자동으로 생성될 수 있습니다.

그래서 나는 이것을 다시 검토하고 있습니다. 제 노드 스크립트 외에 이것에 대한 좋은 해결 방법이 있습니까?

나는이 솔루션을 사용해 왔습니다.
https://github.com/Microsoft/TypeScript/issues/16577#issuecomment -343610106

그러나 모듈에 파일 확장자가 없지만 올바른 MIME 유형이 제공되면 해결되어야 한다고 생각합니다.

이에 대한 움직임이 있습니까?

https://github.com/Microsoft/TypeScript/pull/25073에서 이 문제를 해결할 수 있습니까?

@Kingwl 다른 파일 확장자를 지원하시겠습니까? 예: .mjs .es .esm .

아닐 수도 있습니다. 이것은 또 다른 기능입니다.

어떻게 이런 일이? 타입스크립트 컴파일러는 대상 출력이 JS 파일이라는 것을 _알고_ 있습니다. 15분 동안 이 스레드를 탐색했지만 확장자가 생략된 이유를 여전히 이해하지 못합니다.

이 문제에 대한 참조 수를 보면 올바른 방향으로 가고 있다고 가정합니다. 곧 다른 시도를 할 것입니다.

어떻게 이런 일이? 타입스크립트 컴파일러는 대상 출력이 JS 파일이라는 것을 _알고_ 있습니다. 15분 동안 이 스레드를 탐색했지만 확장자가 생략된 이유를 여전히 이해하지 못합니다.

사람들이 사용하는 일반적인 사용 사례가 있습니다. 확장 기능이 없어 인프라가 더 유연해집니다. 노드 필요 후크 및 웹팩 로더가 두 가지 경우입니다.

어떻게 이런 일이? 타입스크립트 컴파일러는 대상 출력이 JS 파일이라는 것을 _알고_ 있습니다. 15분 동안 이 스레드를 탐색했지만 확장자가 생략된 이유를 여전히 이해하지 못합니다.

사람들이 사용하는 일반적인 사용 사례가 있습니다. 확장 기능이 없어 인프라가 더 유연해집니다. 노드 필요 후크 및 웹팩 로더가 두 가지 경우입니다.

브라우저 모듈 중 어느 것도 신경 쓰지 않습니다.

.js 확장자를 내보내는 옵트인 플래그를 추가하기 위해 typescript 팀을 죽이겠습니까? 우리는 우리가 여기서 무엇을 하는지 알고 있습니다. 그렇지 않으면 여전히 응답과 혼란스러운 질문을 받고 있는 12개의 스레드(공개 및 비공개)가 없을 것입니다. 우리는 그것이 TS의 결함이 아니라는 것을 이해하지만 TS가 JS 문제를 해결하기 위해 여기에 있다면 이 문제를 목록에 추가하십시오.

부인 성명:

예, 많은 사람들이 여기에 "웹팩을 망쳤습니다"라는 문제를 게시할 수 있지만 실제로는 그 사람들에게 힘든 가슴을 일으킬 수 있다는 것을 이해합니다. 옵트인 되어 있어야 합니다.

Btw, TypeScript 소스를 파헤쳐 보니 importModuleSpecifierEnding -- 이미터가 .js 엔딩을 사용하도록 하는 데 (ab) 사용될 수 있습니까?

이 제안을 tsconfig 스키마로 뭉개버릴 수 있습니까? https://github.com/domenic/package-name-maps

이 시점에서 TypeScript가 tsconfig에 지정된 paths 를 사용하여 가져오기를 자동으로 다시 작성할 수만 있다면 기쁠 것입니다. 브라우저 지원이 없어도 대부분의 고충을 해결할 수 있습니다.

업데이트가 있습니까? 이 문제를 해결하려는 시도가 있습니까? 우리는 기본적으로 es 모듈을 지원하는 모든 주요 브라우저를 가지고 있으며, 이에 대한 표준에는 확장이 필요 합니다. 나는 그것을 수동으로 추가할 수 있고 tsc가 그것을 이해할 것이라는 것을 이해하지만 이것이 필수는 아니어야 합니다. 왜 그냥 작동할 수 없습니까?
징징거려서 죄송하지만 이 문제는 이제 매우 오래되었고 아직 수행된 작업이 없습니다...

어떻게 이런 일이? 타입스크립트 컴파일러는 대상 출력이 JS 파일이라는 것을 _알고_ 있습니다. 15분 동안 이 스레드를 탐색했지만 확장자가 생략된 이유를 여전히 이해하지 못합니다.

사람들이 사용하는 일반적인 사용 사례가 있습니다. 확장 기능이 없어 인프라가 더 유연해집니다. 노드 필요 후크 및 웹팩 로더가 두 가지 경우입니다.

그러면 Typescript 컴파일러가 확장을 추가할지 여부에 대한 옵션을 수락할 수 있습니다. 포함 옵션(https://www.typescriptlang.org/docs/handbook/tsconfig-json.html)과 같이 확장을 추가(또는 제외)하기 위해 정규식 집합을 허용할 수도 있습니다.

예, 이미 한 번 이상 제안된 적이 있습니다. 고려하지 않는 이유는 무엇입니까? TS에는 브라우저에 구현된 후에 미래에 변경될 수 있는 실험 기능이 이미 거의 없지만 TS에는 이러한 불안정한 사양에 대한 플래그가 이미 있습니다. module += '.js' 만 수행하는 실험 플래그 addImportsExtensions 만 있으면 되지 않겠습니까? 그게 전부입니다! 펑키한 논리나 추가 기능이 없습니다. 별도의 대상으로 유지하려는 경우 다른 대상이 될 수 있습니다. 그 외에도 위의 내용 중 하나라도 수락하면 개인적으로 tsc 코드를 살펴보고 이에 대한 PR을 작성합니다. 어쨌든 수락되지 않으면 시간을 낭비하고 싶지 않습니다.

사용자 정의 변환을 사용하여 내보낸 코드에서 가져오기를 다시 작성할 수 있습니다('.js' 추가 또는 모듈 가져오기의 확인된 경로 사용).

TypeScript 변환을 작성하는 방법
ttypescript: 컴파일 중 변환을 적용하는 tsc 용 래퍼

필요한 작업을 수행하는 기존 변환이 이미 있을 수 있습니다.

나는 그것이 가능하다는 것을 알고 있습니다. 저는 컴파일러 API를 꽤 많이 가지고 놀았습니다(원하는 만큼은 아니지만). 문제는 프로젝트에 추가 도구를 추가하고 추가 도구에는 문제에 충분히 빠르게 응답할 수도 있고 그렇지 않을 수도 있는 추가 유지 관리자가 있다는 것입니다(종종 그들의 잘못이 아니라 우리 모두는 생명과 일이 있음). 소규모 프로젝트는 종종 포기되고 모든 것을 스스로 수행하면 비즈니스 코드를 관리하는 대신 도구에 시간을 할애하는 책임이 우리에게 이전됩니다.
위의 사항을 고려하면 많은 프로젝트에서 이를 솔루션으로 고려하지 않고 대신 롤업 등과 같은 추가 빌드 단계를 추가하여 추가 구성 오버헤드를 추가하고 추가 유지 관리 비용으로 돌아가게 됩니다.
요약하자면, 저는 (시간이 없거나 다른 많은 이유로 인해) 결국 중단할 수 있는 사용자 지정 솔루션에 시간을 보내는 것보다 공식 TS에 대한 PR에 시간을 보내는 것을 선호합니다. ), 또는 세계의 다른 사람이 사용할 수 없는 것입니다.

@ajafff ​​해결책이 될 수도 있겠지만 가장 큰 문제는 다음과 같다고 생각합니다. Typescript 변환기가 브라우저에서 잘못된 소스 코드를 생성합니다. 변형이 있는 것은 좋지만 해결 방법으로 생각합니다. 변환 세부 사항에 대해 신경을 써야 하고 자체 변환을 구현해야 하는지 아니면 컴파일러에서 관리해야 하는 것인지 궁금합니다.

변환은 정말 강력한 도구입니다. 변환으로 완전히 새로운 트랜스파일러를 작성할 수 있지만 이것은 올바른 방법이 아니라고 생각합니다.

예, 이미 한 번 이상 제안된 적이 있습니다. 고려하지 않는 이유는 무엇입니까? TS에는 이미 실험적인 기능이 거의 없습니다.

TypeScript에는 3년 전에 추가된 정확히 하나의 실험 플래그가 있으며 현재 제안과 더 이상 호환되지 않는 ECMAScript 제안을 위한 것입니다.

Typescript 변환기가 브라우저에서 잘못된 소스 코드를 생성합니다.

나는 당신의 기대를 이해하지만 컴파일러가 당신이 쓴 경로를 다시 쓰지 않는다는 점을 감안할 때 당신이 자신의 코드의 가져오기가 "잘못된" 것이라고 생각하지 않는다는 점에 놀랐습니다. 😉

죄송합니다 @DanielRosenwasser , npm이라는 것을 들어 보셨습니까? 사람들은 그곳에 패키지를 게시하여 우리 모두가 사용할 수 있습니다. 나는 당신이 나를 매우 높게 생각할 수도 있다는 것을 이해하지만 슬프게도 나는 대부분의 저자가 아니기 때문에 확장자를 추가하여 편집할 수 없습니다.
내 프로젝트에서 내 코드만 사용했다면, (WebStorm은 제외하고) 코딩에서 진정한 내 오른손이기 때문에 typescript가 제공하는 것에 대해 더 감사할 것입니다. 그러나 나는 우리 대부분이 생각하는 것처럼 타사 패키지를 사용하고 있으며 반드시 확장이 포함되어 있지는 않습니다. rxjs와 같은 일부 프로젝트는 typescript가 확장 기능을 추가하는 방법을 제공할 것이라는 희망을 품고 문자 그대로 기다립니다. 그렇지 않으면 전체 빌드 프로세스를 변경해야 하므로 제품 대신 도구에 추가 시간을 할애합니다.
이제 3가지 질문에 답변해 주시겠습니까?

1. 타이프스크립트 팀에서 이 기능을 기꺼이 제공할 의향이 있습니까?
2. 그렇다면 PR을 수락하시겠습니까?
3. 아니라면 언제 출시할 예정인가요?

첫 번째 질문에 대한 대답이 '아니오'인 경우 이 기능을 제공할 의사가 없음을 공식적으로 선언하고 이 기능을 제공하지 않을 경우 다른 사람을 기다리게 하지 않음을 공식적으로 선언하면서 이 문제를 닫으십시오.

예, 이미 한 번 이상 제안된 적이 있습니다. 고려하지 않는 이유는 무엇입니까? TS에는 이미 실험적인 기능이 거의 없습니다.

TypeScript에는 3년 전에 추가된 정확히 하나의 실험 플래그가 있으며 현재 제안과 더 이상 호환되지 않는 ECMAScript 제안을 위한 것입니다.

Typescript 변환기가 브라우저에서 잘못된 소스 코드를 생성합니다.

나는 당신의 기대를 이해하지만 컴파일러가 당신이 쓴 경로를 다시 쓰지 않는다는 점을 감안할 때 당신이 자신의 코드의 가져오기가 "잘못된" 것이라고 생각하지 않는다는 점에 놀랐습니다. 😉

@DanielRosenwasser 의 좋은 지적입니다. Typescript 사양 (https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#11.3)을 올바르게 읽는 것처럼 보이기 때문에 제 코드가 맞다고 생각했습니다.

ECMAScript 사양을 읽었다고 확신합니다. 사양에서 모듈이 확장자로 끝나야 하는지 여부는 결정되지 않습니다. 사양에서 모듈 가져오기는 HostResolveImportedModule 알고리즘을 사용하여 해결되지만 정의가 모호합니다. 문제는 ECMAScript 사양이 아닙니다. 문제는 브라우저가 사양에 정의된 [ModuleRequest]가 리소스 경로인 것처럼 모듈을 해결한다는 것입니다.

이를 염두에 두고 해당 언어의 홈 페이지( https://www.typescriptlang.org/ )로 이동하십시오.

페이지 바닥글에서 다음 행을 읽을 수 있습니다.

JavaScript로 시작하고 끝남

TypeScript는 오늘날 수백만 명의 JavaScript 개발자가 알고 있는 것과 동일한 구문 및 의미에서 시작합니다. 기존 JavaScript 코드를 사용하고 인기 있는 JavaScript 라이브러리를 통합하고 JavaScript에서 TypeScript 코드를 호출합니다.

TypeScript 는 모든 브라우저, Node.js 또는 ECMAScript 3(또는 그 이상)을 지원하는 모든 JavaScript 엔진에서 실행되는 깨끗하고 간단한 JavaScript 코드로 컴파일됩니다.

모든 브라우저에서 실행되는 코드를 약속하지만 사실이 아닌 것 같아서 이 문제가 1년 이상 지속됩니다.

@Draccoz 가 지적했듯이 우리는 이 문제로 무엇을 하고 있는지 알고 싶을 뿐입니다. 하지만 이번 호에서는 홈페이지에서 한 가지를 읽고 그 반대를 읽는 것이 조금 답답합니다.

아니요, 우리는 Node의 ES interop과 처음에 npm에서 사용할 전이적 종속성을 전달하기 위한 합리적인 전략과 같은 것에 대한 명확성이 있을 때까지 이와 관련된 어떤 것도 기꺼이 제공하지 않습니다. TypeScript를 사용하지 않았다면 종속성 관리 및 해결과 관련하여 동일한 문제가 발생하므로 JS 에코시스템 전체에서 독립적으로 개발할 수 있는 것을 생각해내는 것은 의미가 없습니다. 그러나 이러한 문제가 해결되었다 하더라도 이 기간 동안 변경이 있을 것이라고 보장할 수는 없습니다.

모든 브라우저에서 실행되는 코드를 약속하지만 사실이 아닌 것 같아서 이 문제가 1년 이상 지속됩니다.

나는 이 해석이 너무 직설적이라고 생각한다. var fs = require('fs') 는 브라우저에서 실행하면 작동하지 않고 HTMLDivElement 는 Node에 정의되어 있지 않으며 String.prototype.startsWith 는 이전 브라우저에서 작동하지 않습니다. 이를 해결하기 위해 사람들은 더 광범위한 JavaScript 생태계에 적용되기 때문에 TypeScript 외부에 도구 및 라이브러리/폴리필을 만들었습니다.

이 문제를 닫아주시겠습니까? 이것은 TS가 하기를 기다리 거나 당신이 하지 않는다고 선언하는 다른 프로젝트를 위한 차단기입니다. 간단한 플래그를 추가할 수 없다면 이 문제를 종료하고 다른 사람들에게 귀하의 결정을 알리십시오.

@DanielRosenwass 빠른 응답에 감사드립니다. 정말 감사합니다. 현명한 선택이라고 생각합니다.

나는 이 해석이 너무 직설적이라고 생각한다. var fs = require('fs')는 브라우저에서 실행할 때 작동하지 않고 HTMLDivElement는 Node에 정의되어 있지 않으며 String.prototype.startsWith는 이전 브라우저에서 작동하지 않습니다. 이를 해결하기 위해 사람들은 더 광범위한 JavaScript 생태계에 적용되기 때문에 TypeScript 외부에 도구 및 라이브러리/폴리필을 만들었습니다.

물론 그렇습니다. 그러나 Typescript에 대해 아무것도 모르는 사람이 다른 무엇을 생각할 수 있겠습니까? 내 해석이 너무 직설적이라는 사실은 이 텍스트가 Typescript에 대해 아무것도 모르는 사람을 "혼동시킬" 수 있다는 사실만큼이나 사실입니다 😉.

실제 동작을 반영하기 위해 문서 (https://www.typescriptlang.org/docs/handbook/modules.html) 를 업데이트할 수 있습니다.

@DanielRosenwass 귀하의 응답에 다시 한 번 감사드립니다. 나는 1년 동안 비슷한 것을 기다려왔다.

이 기능을 원했던 이유는 빌드 도구 없이 어떤 종류의 웹 앱을 만들 수 있는지 확인하기 위함이었습니다. 그때까지는 내가 이전에 작성한 스크립트를 사용할 수 있습니다.

오늘날 브라우저에서 ES 모듈과 TypeScript를 사용할 수 있는 솔루션을 찾고 있는 나와 같은 사람들을 위해 https://github.com/guybedford/es-module-shims를 찾았습니다. 사양 확정 및 브라우저 구현을 기다리는 동안 패키지 이름 맵에 대한 일종의 폴리필 역할을 합니다. TypeScript(TS 컴파일러 제외)에서 간단한 웹 앱을 작성할 때 빌드 도구를 사용하지 않으려는 @QuantumInformation 의 문제(내 문제도 마찬가지)를 해결합니다.

import 'knockout'

export class MyViewModel {
    greeting: KnockoutObservable<string>
    target: KnockoutObservable<string>
    constructor() {
        this.greeting = ko.observable('hello')
        this.target = ko.observable('world')
    }
}

<!DOCTYPE html>


md5-f28d4b503a1603c40bfeb342f341bfbe


<main>
    <span data-bind='text: `${greeting()} ${target()}`'></span>
    <script type='module-shim'>
        import 'knockout'
        import { MyViewModel } from 'index'
        ko.applyBindings(new MyViewModel())
    </script>
</main>

이론적으로, 일단 패키지 이름 맵이 브라우저에서 지원되면 HTML 파일에서 type='module-shim' 를 type='module' 로 찾거나 바꿀 수 있고 packagemap 스크립트를 최종적으로 packagemap 포함을 위해 최종적으로 변경하는 것으로 변경할 수 있습니다. 투기.

.js 확장자는 브라우저나 그 밖의 다른 것들에 의해 요구되지 않는다는 점도 주목할 가치가 있습니다. 웹서버를 unpkg 이상으로 구성하고 .js 파일을 제공할 수 있습니다. 확장 없는 요청 URL. 웹 서버 측에서 모두 구성할 수 있습니다.

@weswigham 매우 문제가 될 수 있습니다. 왜냐하면 tsc(및 클래식 노드 모듈 해상도)는 ./foo 및 ./foo.js 가 동일한 파일을 참조한다는 것을 알고 있기 때문입니다. 웹서버 리디렉션. 가져올 때마다 정확히 같은 방식으로 파일을 참조해야 합니다.

그건 그렇고, 이 문제는 TypeScript 생성 모듈이 오늘날 브라우저에서 사용되는 것을 막지 못합니다. 항상 .js 확장자를 가진 파일을 가져오십시오. tsc는 올바른 일을 하고 .ts 파일에서 유형을 확인하고 브라우저 호환성을 얻습니다.

@weswigham 웹 서버에 액세스하지 않고 파일을 제공하는 상황이 있음을 명심하십시오. GitHub Pages, IPFS, S3 등. 단일 페이지 앱 프레임워크의 출현으로 "서버리스"를 실행하는 것이 점점 더 일반화되고 있습니다(여기서 서버리스는 자산 제공을 제어/구성하는 서버 없이 의미함). apple 에 대한 요청이 있을 때 apple.js 를 제공하기 위해 서버 측 필터에 의존할 수 없습니다.

가져올 때마다 정확히 같은 방식으로 파일을 참조해야 합니다.

작성 기본 설정에 따라 항상 하나 또는 다른 404를 만들 수 있습니다. 프로젝트 내에서 심볼릭 링크를 사용한 경우 처리 방법을 선택해야 하는 유사한 문제가 발생합니다.

항상 .js 확장자를 가진 파일을 가져오기만 하면 됩니다.

예, 그것도 잘 작동합니다.

@QuantumInformation 여기에 사용된 스니펫이 공개용인가요? 프로젝트에서 사용할 수 있습니까? 😃

@distante 네 사용할 수 있습니다

참고로 Jest를 사용하여 소스에서 .js에 대한 확장을 테스트하고 변경하는 경우 - 중단됩니다.
하지만 jest 구성에 다음을 추가하여 문제를 해결할 수 있습니다.

  "jest": {
    ...
    "moduleNameMapper": {
      "(.*)\\.js": "$1"
    }
  }

안녕하세요 @MrAntix ,

나는 jest가 TypeScript에 적응해야 하는 라이브러리이지 그 반대가 아닌 라이브러리라고 생각합니다.

빌드 도구를 사용하지 않으려는 다른 사이트가 있습니다. 이것이 우리의 최고입니까?

https://github.com/microsoft/TypeScript/issues/16577#issuecomment -452312753

이 문제를 해결하려면 다음과 같이 하면 됩니다(js가 아닌 ts 파일이더라도) 😢

누군가 그것을 시도하고 싶다면:
https://github.com/QuantumInformation/web-gen-bot

그러나 현재 tsconfig에서 작동하도록 소스 디버깅을 가져올 수 없으며 다시 보고합니다.

결국 나는 webpack으로 돌아갔고 node_modules는 브라우저의 빌드 도구에서 벗어나려고 할 때 킬러였습니다.

Jest 뿐만이 아닙니다. 게시하기 전에 TypeScript를 컴파일하기 위해 tsc 를 사용하는 경우 결과 패키지를 가져오는 모든 JS 모듈은 모듈 해상도의 차이로 인해 중단됩니다.

여기서 논의는 두 가지 관련되지만 궁극적으로 별개의 문제로 약간 갈라진 것 같습니다.

• Typescript는 브라우저에서 기본적으로 로드할 수 있는 파일을 생성해야 합니다.
• Typescript는 노드 모듈 경로가 항상 유효한 URL이 아니라는 사실을 해결해야 합니다.

두 번째 문제는 분명히 typescript만으로는 해결할 수 없는 문제이므로 첫 번째 문제에 집중해야 한다고 생각합니다.

그러나 첫 번째 문제는 Typescript가 해결할 수 있고 우선순위를 지정해야 하는 문제입니다. Typescript를 사용하여 최신 브라우저를 대상으로 하는 웹앱을 구축하려는 대부분의 사람들에게 주요 차단기이기 때문입니다.

제 생각에 문제는 다음과 같이 요약됩니다.

tsc 를 실행하면 확장자가 .js 인 파일 하나가 생성되고 첫 번째 .js 파일을 가져오는 다른 파일이 생성되면 사용할 확장명이 모호하지 않으며 확장자를 포함하는 옵션입니다.

Typescript가 생성하는 파일 이외 의 파일을 가리키는 모든 import 문에 대해 (Typescript가 오늘날 하는 것처럼) 변경되지 않은 상태로 두는 것이 좋다고 생각합니다.

첫 번째 옵션에 따르면 명령줄 arg가 가장 좋고 기본적으로 꺼져 있습니다. 내가 webpack을 사용하는 경우 webpack이 모듈 번들링을 처리하므로 가져오기에 .js가 추가되는 것을 원하지 않기 때문에 이 말을 하는 것입니다.

어쨌든 node_modules는 네이티브 모듈 브라우저 앱에 대한 해킹 을 사용하지 못하게 한 킬러였습니다.

내가 webpack을 사용하는 경우 webpack이 모듈 번들링을 처리하므로 가져오기에 .js가 추가되는 것을 원하지 않기 때문에 이 말을 하는 것입니다.

Webpack은 .js 확장자를 완벽하게 처리하므로 차이가 없습니다.

실제로 Webpack과 함께 .js 를 사용해야 하는 경우가 있습니다(이름은 같지만 확장자가 다른 파일이 여러 개 있는 경우).

Webpack으로 .js 가져오기를 원하지 않는 이유에 대해 자세히 설명해 주시겠습니까?

내가 I don't want 라고 말할 때 나는 내 유스 케이스에 필요하지 않다는 것을 의미했습니다.

기본 동작이 되어서는 안 되는 강력한 이유를 찾지 못했습니다(항상 다른 구성 플래그를 추가하는 것을 꺼려합니다...)

가져오기를 .js 로 설정하면 ts-node가 파일에 대해 제대로 작동하지 않습니다. 이것은 ts-node가 한 번에 하나의 파일만 컴파일하고 방출된 파일 내용이 require('./foo.js') 로 끝나는 경우 nodejs가 해당 파일을 처리할 때 존재하지 않는 ./foo.js 로드를 시도하기 때문입니다. 디스크의 모든 위치에 있으므로 실패합니다. 반면에 코드가 require( ./foo )를 수행하지 않으면 ts-node의 핸들러가 호출되어 ./foo.ts 를 JS로 컴파일하고 반환할 수 있습니다.

TypeScript가 모든 경우에 .js 확장을 내보내면 ts-node에서 동일한 문제가 발생합니다. 그러나 확장이 자동으로 추가되는지 여부를 토글하는 옵션이 있는 경우 ts-node는 해당 컴파일러 옵션을 해제하여 현재 시스템이 계속 작동하도록 할 수 있습니다.

Node.js --experimental-modules 에는 필수 파일 확장자가 필요하므로 이에 대한 API는 종속성 분석 없이 간단합니다 --jsext 와 같은 옵션은 $ .ts 확장자를 .js 로 다시 작성할 수 있습니다. import 'npmpkg.ts' .ts 로 끝나는 패키지 이름입니다. 이 경우는 극히 드물지만 해결에서 포괄적으로 처리하려면 다음 행을 따라 _bare specifiers_에 대한 예외를 만드는 것이 규칙이 될 수 있습니다. - 만약 베어 지정자(URL 또는 상대 경로가 아님)가 유효한 npm 패키지 이름( 일치하는 /^(@[-_\.a-zA-Z\d]+\/)?[-_\.a-zA-Z\d]+$/ , from https://github.com/npm/validate-npm-package-name) 그런 다음 재작성에서 .ts 확장을 무시합니다.

.js 파일 확장자를 상대 가져오기 경로에 추가하는 TypeScript 컴파일러 변환기를 만들었습니다. 즉, .ts 파일에 import { Foo } from './foo' 가 있으면 import { Foo } from './foo.js' 가 발생합니다. NPM에서 사용할 수 있으며 사용 방법에 대한 지침은 프로젝트 추가 정보에서 찾을 수 있습니다.

https://github.com/Zoltu/typescript-transformer-append-js-extension

이와 같은 것이 TypeScript 컴파일러에 통합된다면(컴파일러 옵션으로) .js 확장자를 추가할 때와 추가하지 않을 때를 결정하는 것이 더 현명할 것입니다. 지금은 ./ 또는 ../ 로 시작하는 경로를 찾고 경로의 다른 곳에는 . 가 없습니다. 이것은 누군가가 _실제로_ 그러한 극단적인 경우에 부딪힐지 여부에 의문을 제기하지만, 여러 가지 극단적인 경우 시나리오에서 올바른 일을 하지 않는다는 것을 의미합니다.

@MicahZoltu 이에 대한 userland 솔루션을 보니 반갑습니다. TypeScript 확장 옵션이 _컴파일 시 .ts 확장을 .js 확장으로 전환_할 수 있도록 멘탈 모델이 항상 파일 확장을 포함 하는 것이 중요하다고 생각합니다. 이렇게 하면 해결 문제를 피하고 ".ts"로 끝나는 npm 패키지 이름의 경우만 남게 되며, 이는 이전 의견에서 논의한 대로 처리할 수 있습니다.

@guybedford .ts 파일에 .js 확장자를 포함하면 ts-node에서 파일을 실행할 수 없습니다. ts-node에서 문제를 해결하는 것은 NodeJS가 파일 확인을 수행하는 방식으로 인해 결코 간단하지 않습니다. 즉, 하드 코딩된 .js 확장자가 있는 라이브러리를 게시하면 라이브러리가 ts-node를 사용하는 모든 사람에게 작동하지 않습니다. https://github.com/TypeStrong/ts-node/issues/783에서 이에 대한 토론을 참조하십시오.

@MicahZoltu 내 말은 .ts 파일에 .ts 확장자를 포함하는 것입니다.

@guybedford .ts 파일에 .js 확장자를 포함하면 ts-node에서 파일을 실행할 수 없습니다.

이것이 노드와 브라우저에서 TypeScript를 자동 실행하는 것이 나쁜 생각인 또 다른 이유입니다.

@MicahZoltu .ts 파일에 .ts 확장자를 포함하는 것을 의미합니다.

나는 이것의 문제가 .ts 파일과 .js / .d.ts 쌍 사이의 동등성을 깨뜨린다고 생각합니다. 즉, 현재 프로젝트로 컴파일된 파일을 가져오는 경우 .ts 를 사용하고 파일을 다른 프로젝트로 이동하는 경우 .js 를 사용하도록 가져오기를 변경해야 합니다. .

이것은 또한 출력이 변압기 없이 표준 환경에서 작동하지 않는다는 것을 의미합니다. .tsconfig 파일에서 변환기를 설치할 방법이 없다는 점을 감안할 때 항상 사용자 정의 컴파일러를 사용해야 한다는 의미입니다. .js .ts 를 사용하는 작은 이점을 위해 배치하는 것은 꽤 큰 장벽입니다.

즉, 현재 프로젝트로 컴파일된 파일을 가져오는 경우 .ts를 사용하고 파일을 다른 프로젝트로 이동하는 경우 .js를 사용하도록 가져오기를 변경해야 합니다.

외부/내부 수입 경계는 잘 정의된 것입니다. 종속성이 현재 동일한 빌드의 내부 .ts 파일에서 별도의 빌드가 있거나 TypeScript가 아닐 수도 있는 다른 패키지 가져오기의 외부 .js 파일로 이동하는 경우 , 그러면 네, 완전히 다른 개념이므로 확장자를 변경해야 합니다.

이것은 또한 출력이 변압기 없이 표준 환경에서 작동하지 않는다는 것을 의미합니다.

변환기가 이를 탐색하는 데 도움이 될 수 있지만 --ts-to-js 또는 이와 유사한 컴파일러 플래그/옵션은 이 문제를 해결하는 데 매우 필요합니다.

@guybedford .ts 를 넣는 것이 플러그인에 대해 올바른 일이라고 저를 설득하셨습니다. 그러나 그것을 구현하려고 했을 때 TypeScript가 실제로 그것을 허용하지 않는다는 것을 배웠습니다!

// foo.ts
export function foo() { console.log('foo') }

// bar.ts
import { foo } from './foo.ts' // Error: An import path cannot end with a '.ts' extension. Consider importing './foo' instead
foo()

안녕하세요, 이것은 어떻습니까?

입력:

// src/lib.js.ts
export const result = 42;

// src/index.js.ts
import { result } from "./lib.js";

console.log(result);

산출:

// build/lib.js
export const result = 42;

// build/index.js
import { result } from "./lib.js";

console.log(result);

문제 #30076

TypeScript 파일의 유일한 .ts 확장자가 나에게 가장 적합하다고 생각합니다. 종종 컴파일 시간까지 대상이 무엇인지 알지 못합니다. 예를 들어, 많은 라이브러리 프로젝트에는 .js 파일을 내보내고 가져오기 경로를 .js 에 매핑해야 하는 최신 브라우저를 대상으로 하는 것과 같이 다양한 환경을 대상으로 하는 여러 tsconfig.json 파일이 있습니다. 또는 .mjs 파일을 내보내고 가져오기 경로를 .mjs 에 매핑해야 하는 최신 노드를 대상으로 합니다.

.ts 로 끝나는 파일을 가져오는 것이 오류라는 @MicahZoltu 는 실제로 우리에게 이익이 될 수 있습니다. 이는 플래그 없이 .ts 확장을 사용할 때마다 컴파일 시 .ts ~ .js 확장 재작성을 추가할 수 있음을 의미하기 때문입니다. :)

후행 .ts 확장을 지원하고 .js 확장으로 다시 쓰는 PR(이 기능을 활성화하는 플래그 아래 있을 수 있지만 시간이 지나면 제거할 수 있는 플래그)이 좋은 방법일 것입니다. 이 경로를 따라 시작합니다.

//cc @DanielRosenwasser

이 문제는 이미 너무 길기 때문에 누군가가 이미 이것을 말했을 수 있으므로 이미 말한 것을 반복할 위험이 있습니다.

TypeScript는 유효한 JavaScript이기 때문에 개발자가 import 에 확장을 지정할 수 있도록 해야 합니다. 그리고 이것은 JS/TS 확장에 관한 것이 아닙니다! ESM에서는 MIME 유형이 정확하기만 하면 모든 확장이 유효합니다.

import actuallyCode from './lookLikeAnImage.png';

...서버가 해당 파일에서 유효한 JavaScript를 제공하고 올바른 MIME 유형을 설정하는 한 유효해야 합니다. 이것은 TS에 대해서도 마찬가지일 수 있으므로 더 나아갑니다! TS 파일은 JS MIME 유형과 함께 제공되는 JS 소스 코드일 수 있으므로 ESM 모듈 가져오기를 위한 유효한 경로입니다.

IMO TypeScript는 (오늘날 원하는 것처럼) 확장자가 없는 가져오기만 고려하고 오류, 경고 등이 없는 확장자를 그대로 두어야 합니다. 그렇지 않으면 JS의 상위 집합이라고 주장하는 것에 대해 꽤 불행한 유효한 JavaScript 코드를 거부합니다.

이것이 이것을 제기하기에 적합한 장소가 아니라면 죄송합니다. 나는 몇 가지 다른 문제를 보았습니다: #18971, #16640, #16640 그러나 이 주제에 대한 문제는 좌우로 닫혀 있는 것 같으므로 이것이 "주요" 문제라고 가정합니다. 열린 상태를 유지하도록 허용했기 때문입니다.

NodeJS v12.7.0 사용하기

salathiel@salathiel-genese-pc:~/${PATH_TO_PROJECT}$ node --experimental-modules dist/spec/src/ioc
(node:15907) ExperimentalWarning: The ESM module loader is experimental.
internal/modules/esm/default_resolve.js:59
  let url = moduleWrapResolve(specifier, parentURL);
            ^

Error: Cannot find module '${PROJECT_ROOT}/dist/spec/src/ioc' imported from ${PROJECT_ROOT}/
    at Loader.resolve [as _resolve] (internal/modules/esm/default_resolve.js:59:13)
    at Loader.resolve (internal/modules/esm/loader.js:73:33)
    at Loader.getModuleJob (internal/modules/esm/loader.js:149:40)
    at Loader.import (internal/modules/esm/loader.js:133:28)
    at internal/modules/cjs/loader.js:830:27
    at processTicksAndRejections (internal/process/task_queues.js:85:5) {
  code: 'ERR_MODULE_NOT_FOUND'
}

salathiel@salathiel-genese-pc:~/${PATH_TO_PROJECT}$ node --experimental-modules dist/spec/src/ioc.js
(node:16155) ExperimentalWarning: The ESM module loader is experimental.
internal/modules/esm/default_resolve.js:59
  let url = moduleWrapResolve(specifier, parentURL);
            ^

Error: Cannot find module '${PROJECT_ROOT}/dist/spec/src/observe' imported from ${PROJECT_ROOT}/dist/spec/src/ioc.js
    at Loader.resolve [as _resolve] (internal/modules/esm/default_resolve.js:59:13)
    at Loader.resolve (internal/modules/esm/loader.js:73:33)
    at Loader.getModuleJob (internal/modules/esm/loader.js:149:40)
    at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:43:40)
    at link (internal/modules/esm/module_job.js:42:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}

이제 이게 왜 짜증나는지 모르겠네요...

현재 TypeScript는 경로를 다시 작성하지 않습니다. 확실히 짜증나지만 현재 .js 확장자를 직접 추가할 수 있습니다.

@DanielRosenwasser https://github.com/microsoft/TypeScript/issues/16577#issuecomment -309169829

옵션 뒤에 구현하는 것은 어떻습니까? --rewrite-paths ( rewritePaths: true ) ?

https://github.com/microsoft/TypeScript/issues/13422#issuecomment -521169737

@viT-1 당분간 해결 방법은 다음과 같습니다. https://github.com/microsoft/TypeScript/issues/16577#issuecomment -507504210

@MicahZoltu SystemJS 번들링(tsconfig outFile 옵션)으로 내 유스케이스 를 해결합니다.

나는 사람들이 이것에 대해 쓴 모든 댓글을 읽지는 않았지만 왜 내가 .js 를 엄청나게 많이 써야 하는지 이해하지 못합니다. 나는 컴퓨터가 나를 위해 그것을 해주기를 원한다.

@richardkazuomiller 우리 모두 그렇게 하고 있지만 @DanielRosenwasser 는 https://github.com/microsoft/TypeScript/issues/16577#issuecomment -448747209에서 그들이 지금 당장은 그렇게 할 의향이 없다고 밝혔습니다(이 문제가 여전히 오해의 소지가 있게 열려 있다는 점에 놀랐습니다. 위의 진술 이후 오랫동안). 컴퓨터가 자동으로 수행하도록 하려면 번들러 또는 타사 도구를 사용하여 가져오기 경로 재작성을 처리하는 것이 좋습니다.

누가 이 문제를 종료하기를 원합니까?

닫지 마십시오. TypeScript 팀이 확장을 사용하고 대신 MIME 유형에 의존하도록 허용하는 ESM 가져오기에 어떻게 접근할지에 대해 여전히 기다리고 있습니다. 현재 이것은 JavaScript에서는 가능하지만 TypeScript에서는 불가능합니다. (자세한 내용은 이전 댓글을 참조하세요.)

@TomasHubelbauer 이것이 내가 구성 파일에 플래그를 제안한 이유입니다. 이는 모든 확장자가 없는 가져오기에 .js(또는 기타 구성된) 확장자가 추가되어야 함을 나타낼 수 있습니다. 이것은 옵트인(opt-in)이므로 기본값이 false일 수 있으므로 기존 프로젝트 또는 요구 사항이 다른 프로젝트가 있는 그대로 작동합니다.

이전에 말했듯이:

어떤 버전의 TS가 추가했는지 확실하지 않지만 ' ./file.js' 와 같은 가져오기가 이제 작동합니다(파일이 실제로 file.ts인 경우에도).
TypeScript는 파일을 잘 해석하고 완전한 .js 가져오기를 대상으로 출력합니다.

유효한 JavaScript가 유효한 TypeScript이기 때문에 이것은 의미가 있습니다. 당신이 할 수 있기 때문에:

import foo from './bar.js'

...JS에서는 TS에서도 할 수 있어야 합니다. 그렇게 하면 확장이 정확하기 때문에 기본 ES6 모듈을 사용하는 문제를 해결할 수 있습니다.

또한 브라우저가 ./foo/bar 에 대한 가져오기를 볼 때 실제로 요청한다는 것을 잊지 마십시오. 아무것도 제공되지 않았다는 사실은 서버 때문이었습니다. /foo/bar /foo/bar.js 만족되도록 구성할 수 있습니다. 이것이 좋은 솔루션이거나 좋은 아이디어라고 말하지는 않지만 기술적으로 작동할 것입니다.

구성 파일에 플래그가 있으면 모든 확장자가 없는 가져오기에 .js(또는 기타 구성된) 확장자가 추가되어야 함을 나타낼 수 있습니다.

이것은 대부분의 경우를 해결할 것입니다. TypeScript 팀이 이 구성 옵션에 대해 PR을 고려할 의향이 있습니까?

NodeJS는 이제 _기본적으로_ 상대 경로 모듈 확인과 관련하여 브라우저와 동일한 방식으로 작동합니다. 더 이상 기본적으로 .js 확장자를 유추하지 않습니다. 이는 TSC의 현재 동작으로 인해 모든 런타임 컨텍스트에서 유효하지 않은 JS가 방출된다는 것을 의미합니다. ESM에 대한 브라우저 및 NodeJS 동작 모두에 대한 명확성이 있으므로 이 문제를 이제 해결해야 할 것 같습니다.

https://nodejs.org/api/esm.html#esm_customizing_esm_specifier_resolution_algorithm

esm용 새 해석기는 새로운 해석 모드가 필요합니다. moduleResolution: node 는 실제로 "이전 버전의 노드"라고 부를 수 있는 cjs 해석기입니다. 새로운 esm 리졸버를 대상으로 하려는 경우 보다 적절하게 일치하는 새로운 해결 모드가 필요합니다. 특히 노드는 모든 기존 구성에서 이전 리졸버를 완전히 지원하기 때문에 특히 그렇습니다. (참고: 그러한 새로운 리졸버를 _우리의 기본값_으로 만드는 것은 어려울 것입니다)

그러나! 그것에 대해 _동의하지 않으며 _일부 사람들은 의견을 사실로 진술하기로 선택할 것입니다_, 예상되는 확장 동작을 반환하고 여전히 기본값이 될 수 있는 --es-module-specifier-resolution=node 플래그가 여전히 있습니다. , es 노드의 모듈은 _여전히 실험적입니다_.

또한 원래 요청에 대한 알림으로 가져오기를 다시 작성하지 않습니다. 항상. 조금도. 지정자 입력 === 지정자 출력. 지정자는 구조적 의도를 설명하며 의도된 구조에서 다른 구조로 암시적으로 매핑하는 것이 우리의 목표가 아닙니다. 다음과 같이 생각할 수도 있습니다. const varFoo = "./Foo"; import(varFoo) 를 작성했다면 필요한 경우 확장자를 추가할 수 있습니까? 아니오 - 말도 안되는 소리입니다 - 모든 형태의 동적 입력을 처리하려면 런타임에 동적 가져오기를 래핑해야 하며 갑자기 내장 플랫폼 로더의 최상위 계층인 자체 모듈 로더가 되었습니다. 대신에 확장을 생략하면 적절하게 오류가 발생하는 리졸버 모드를 제공합니다(이는 의심할 여지 없이 이미 린트 규칙을 찾을 수 있음).

이 스레드를 찾았고 입력 소스에 확장 기능이 없는 것을 _정말 원_하고, (노드 es) 모듈을 대상으로 할 때 출력이 계속 작동하도록 _정말 필요_하다면, https://github.com/ 에서 피드백을 제공해야 합니다.

갑자기 우리는 우리 자신의 모듈 로더가 되었습니다

tsc 는 무슨 일이 있어도 기능적 모듈 로더여야 하지 않습니까? 가져온 모듈을 찾을 수 없으면 가져오기에 대해 유형 검사를 할 수 없습니다. 다양한 모듈 로더가 광범위하게 호환되는 방식으로, 또는 최소한 수용하기에 합리적으로 고통스럽지 않은 예측 가능하게 다른 방식으로 작동하는 것을 보고 싶습니다.

이제 NodeJS는 상대 경로 모듈 확인과 관련하여 기본적으로 브라우저와 동일한 방식으로 동작합니다. 더 이상 기본적으로 .js 확장자를 유추하지 않습니다. 이는 TSC의 현재 동작으로 인해 모든 런타임 컨텍스트에서 유효하지 않은 JS가 방출된다는 것을 의미합니다.

이것이 TypeScript와 같은 지정자에서 .js 파일 확장자를 사용하는 또 다른 이유가 아닙니까? 그러면 확장 없는 가져오기에서 tsc 오류가 발생하는 경우를 제외하고는 모든 것이 해결됩니다.

tsc는 무슨 일이 있어도 기능적 모듈 로더여야 하지 않습니까? 가져온 모듈을 찾을 수 없으면 가져오기에 대해 유형 검사를 할 수 없습니다. 다양한 모듈 로더가 광범위하게 호환되는 방식으로, 또는 최소한 수용하기에 합리적으로 고통스럽지 않은 예측 가능하게 다른 방식으로 작동하는 것을 보고 싶습니다.

우리는 런타임 로더 구현을 제공하는 것을 목표로 하지 않습니다. 대상으로 하는 런타임 로더가 무엇이든 반영하는 컴파일 시간 분석일 뿐입니다. 우리는 가지고 있지도, 갖고 싶지도 않은 런타임 구성 요소 없이 모든 가져오기를 다시 매핑할 수 없습니다.

tsc는 무슨 일이 있어도 기능적 모듈 로더여야 하지 않습니까?

런타임에는 없습니다. tsc 는 선택한 런타임이 지정자를 해결하고 빌드 시 이를 구현하는 방법을 이해해야 하지만 런타임은 순전히 환경에 달려 있습니다.

다음과 같이 생각할 수도 있습니다. const varFoo = "./Foo"; import(varFoo) 필요한 경우 확장자를 추가할 수 있습니까?

@weswigham 이것은 동적 가져오기에 관한 강력한 주장이지만 정적 가져오기로 그렇게 할 수 있다고 _생각_하지 않습니다. 전략이 둘 다 동일해야 한다는 주장은 이해할 수 있지만 정적 가져오기는 동적 가져오기와 매우 다른 역할을 수행한다는 점을 언급할 가치가 있으며 정적 가져오기에 대해 다른 전략을 사용하는 것이 _불합리한_ 것은 아니라고 생각합니다. 가져오기 다시 쓰기 및 동적 가져오기 다시 쓰기.

이것이 TypeScript와 같은 지정자에서 .js 파일 확장자를 이미 지원하는 또 다른 이유가 아닙니까? 확장 없는 가져오기에서 tsc에 오류가 발생하는 경우를 제외하고는 모든 문제가 해결됩니다.

@justinfagnani 두 가지 문제가 있습니다.

1. 가져오기에 .js 확장을 지정하면 TS를 기본적으로 실행하는 런타임(예: TS-Node)이 작동하지 않습니다.
2. 가져오기에 .js 확장자를 포함하면 컴파일러(IMO)에 거짓말을 하는 것입니다.

(2)와 관련하여 두 개의 TS 파일 a.ts 및 b.ts 및 a.ts 가 import ... from './b.js' 하면 컴파일러에게 "나는 형제 파일이 있습니다. 이름이 b.js 입니다. 이 진술은 사실이 아닙니다. 설상가상으로 .b.ts 와 b.js (실제로 서로의 파생물이 아닐 수도 있음)가 모두 있는 경우 이제 _명시적으로 확장을 포함했음에도 불구하고 어느 것을 참조하는지 모호해집니다.

나는 사용자가 (사용자로서) 실제로 무엇을 원하는지 컴파일러에게 말해야 하고 "X 이름과 확장자를 가진 모든 파일을 가져오는 것"( import ... from './foo' 의 경우)을 알려야 한다고 생각합니다. ) 또는 "이 파일을 구체적으로 가져오기"( import ... from './foo.ext' 의 경우). 컴파일러가 TS 파일을 가져오는 것을 감지하고 컴파일러가 .js 파일을 계속 내보내면 컴파일러가 적절한 파일을 올바르게 가져오도록 가져오기를 업데이트해야 한다고 생각합니다. 이것은 import 문에서 .ts 를 .js 로 변경하는 것을 의미할 수 있습니다.

@justinfagnani 두 가지 문제가 있습니다.

1. TS를 기본적으로 실행하는 런타임(예: TS-Node)은 가져오기에 .js 확장자를 지정하면 작동하지 않습니다.

이것은 TS-Node의 버그입니다. tsc 의 동작과 일치하지 않습니다.

1. 가져오기에 .js 확장자를 포함하면 컴파일러(IMO)에 거짓말을 하는 것입니다.

실제로는 그 반대입니다. 실제로 가져올 항목에 대한 진실을 말하는 것입니다. .ts 파일이 아니라 .js 파일을 _가져오지_ 않습니다. 또한 .d.ts / .js 쌍과 .ts 파일 간에 눈에 띄는 차이가 없어야 합니다. 그것들은 교환할 수 있습니다. 이를 수행하는 유일한 적절한 방법은 .js 파일을 가져오는 것입니다. .ts 파일은 컴파일 후 어떻게 될까요?

@justinfagnani

또한 .d.ts/.js 쌍과 .ts 파일 간에 눈에 띄는 차이가 없어야 합니다.

이것은 항상 사실이 아닙니다. JS MIME 유형을 사용하여 모든 JS, TS 및 DTS를 제공하도록 서버를 구성한 다음 JavaScript에서 모두 개별적으로 가져올 수 있으며 런타임은 이를 모두 JS로 충실히 실행합니다. ESM은 확장에 대해 전혀 신경 쓰지 않습니다.

그렇기 때문에 TS 사용자는 실제로 .ts 확장자를 포함해야 하고 확장자가 없는 파일이나 그 이름을 실제로 가져오지 않는 한 확장자가 오류가 될 것이라고 생각합니다. 그리고 TS는 출력에서 ​​가져오기를 .js 로 다시 작성합니다. 그리고 JS 파일이 존재하는 경우(TS에 의해 생성된 파일이 아님) 이것도 오류가 됩니다.

이것은 TS-Node의 버그입니다. tsc의 동작과 일치하지 않습니다.

TS-Node의 버그가 아니라 NodeJS 로더의 제한 사항입니다. https://github.com/TypeStrong/ts-node/issues/783#issuecomment -507437929

이것은 항상 사실이 아닙니다. JS MIME 유형을 사용하여 모든 JS, TS 및 DTS를 제공하도록 서버를 구성한 다음 JavaScript에서 모두 개별적으로 가져올 수 있으며 런타임은 이를 모두 JS로 충실히 실행합니다. ESM은 확장에 대해 전혀 신경 쓰지 않습니다.

나는 그것을 잘 알고 있지만 브라우저도 TypeScript를 실행하지 않을 것입니다. 환경에서 실제로 로드하는 파일이 JavaScript 파일이라는 것은 거의 보편적인 사실입니다.

제 요점은 .js / .d.ts 쌍이 이미 있고 타사 패키지에서 .js 파일을 가져오면 tsc 가 .d.ts 파일을 보고 유형을 로드하십시오. 즉, .js / .d.ts 쌍은 .ts 파일과 같이 _acts_하며 이것이 변경되지 않고 JavaScript에서 TypeScript로 투명하게 이식할 수 있는 방법이므로 이렇게 되어야 합니다. 이식된 파일을 가져옵니다.

이것은 TS-Node의 버그입니다. tsc의 동작과 일치하지 않습니다.

TS-Node의 버그가 아니라 NodeJS 로더의 제한 사항입니다. TypeStrong/ts-node#783(comment)

TS-Node가 tsc 동작에서 벗어나는 것은 여전히 ​​버그입니다. .ts 파일은 tsc 와 TS-Node 모두에서 작동하지 않으며 저는 tsc 를 TS-Node가 따라야 하는 표준 설정자로 강력히 고려할 것입니다. .

제 요점은 제 3자 패키지에서 이미 .js/.d.ts 쌍이 있고 .js 파일을 가져오면 tsc가 .d.ts 파일을 보고 유형을 로드한다는 것입니다. 즉, .js/.d.ts 쌍은 .ts 파일처럼 작동합니다. 이것이 포팅되는 파일의 가져오기를 변경하지 않고 JavaScript에서 TypeScript로 투명하게 포팅할 수 있는 방법이기 때문에 그래야 합니다.

외부 _패키지_를 로드하는 경우 명명된 모듈을 진입점 파일에 매핑하는 일종의 런타임 패키지 로더(예: 브라우저의 명명된 가져오기 맵)가 필요합니다. 그러나 상대적인 .js/.d.ts 쌍이 있는 경우 귀하의 요점은 일반적으로 유효하다고 생각합니다. 나는 그 경우에 import ... from './foo.d.ts' 또는 import ... from './foo.js' 를 해야 하는지 여부를 판단하고 있습니다.

.d.ts 파일은 기본적으로 어떤 확장자에서 매핑되는지에 대한 정보가 포함되지 않은 구조를 설명하는 헤더입니다(일반적으로 같은 위치에 이름은 같지만 확장자가 다른 여러 파일이 있어서는 안 된다고 가정하고, 빌드 시 오류 발생) - 오늘날에도 관련 런타임 "소스"는 .js 또는 .jsx 일 수 있습니다( jsx: preserve 사용). 일반적으로 방출 시 가져오기에서 .d.ts 참조를 .js 로 바꿀 수 없으며 작동한다고 가정할 수 없습니다...

tsc가 더 넓은 범위에 대해 너무 독단적이지 않도록 하는 것이 중요합니다.
빌드 및 해결 가정.

복잡한 경계의 다중 도구라는 점을 감안할 때 예상되는
해당 구성을 통해 사용자가 원하는 방식으로 작동할 수 있습니다.

해상도 변경 사항을 다음과 같이 노출하지 않으려는 매우 의도적인 노력이 있었습니다.
tsc 컴파일 프로세스의 일부 - 그 자체로 의견이 분분합니다.
사용자의 워크플로에 마찰을 일으킵니다.

2019년 11월 27일 수요일 16:48 Wesley Wigham [email protected]
썼다:

.d.ts 파일은 본질적으로 다음을 포함하는 구조를 설명하는 헤더입니다.
어떤 확장자에서 매핑되는지에 대한 정보가 없습니다(가정은
일반적으로 같은 이름의 파일이 여러 개 있어서는 안 되지만
같은 장소에 다른 확장자) - 오늘날에도 연결된
런타임 "소스"는 .js 또는 .jsx(jsx 사용: 보존)일 수 있습니다. 당신은 할 수
일반적으로 방출 시 가져오기에서 .d.ts 참조를 .js로 바꾸지 마십시오.
그리고 그것이 작동한다고 가정하십시오 ...

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/microsoft/TypeScript/issues/16577?email_source=notifications&email_token=AAESFSQS2DQ23RR5KN3RTZ3QV3TLXA5CNFSM4DPRQTY2YY3PNVWWK3TUL52HS4DFVEXG43VMXHJKTDNMV
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAESFSUAP2YO23ZFHCOWVQLQV3TLXANCNFSM4DPRQTYQ
.

이 시나리오를 처리하는 방법이 확실하지 않지만 같은 것과 관련된 의심이 있습니다.

내 html 파일에 다음과 같은 가져오기 맵이 있습니다.

<script type="importmap-shim">
      {
        "imports": {
          "@root/":"../../../",
         }
      }
</script>

그리고 다음과 같은 파일을 가져올 ts 파일이 있습니다.

import '@root/components/page-main/page-main.js';

이제 이 설정은 브라우저에서 잘 작동합니다. 그러나 VSCode에서 어떻게 탐색/사용할 수 있습니까? 내 말은, 가져오기를 ctrl+클릭하고 파일로 이동하고, 자동 완성을 얻고, def 등을 입력하고 싶습니다.

또한 tsc가 .ts에서 .js로 가져오기 확장을 다시 작성하지 않는다는 점을 고려하면 빌드 시 동일한 작업을 수행하는 데 사용할 수 있는 다른 권장 도구/패키지가 있습니까? 감사 해요.

(ES 모듈 및 가져오기 맵에 https://github.com/guybedford/es-module-shims를 사용하고 있습니다)

그러나 VSCode에서 어떻게 탐색/사용할 수 있습니까?

paths 컴파일러 옵션을 찾습니다.

또한 tsc가 .ts에서 .js로 가져오기 확장을 다시 작성하지 않는다는 점을 고려하면 빌드 시 동일한 작업을 수행하는 데 사용할 수 있는 다른 권장 도구/패키지가 있습니까? 감사 해요.

.js 만 사용하면 빌드 시 .ts 파일을 참조하더라도 제대로 작동합니다.

@tvvignesh https://github.com/Zoltu/typescript-transformer-append-js-extension/ 컴파일 시 확장 없는 가져오기를 .js로 다시 작성합니다. 저는 개인적으로 ".js를 TS 파일에 넣으세요"를 좋아하지 않습니다. 그렇게 하면 코드가 ts-node에서 실행되지 않기 때문입니다. ts-node에서 코드를 실행할 필요가 없다면 .js를 사용하면 됩니다.

그러나 VSCode에서 어떻게 탐색/사용할 수 있습니까?

paths 컴파일러 옵션을 찾습니다.

또한 tsc가 .ts에서 .js로 가져오기 확장을 다시 작성하지 않는다는 점을 고려하면 빌드 시 동일한 작업을 수행하는 데 사용할 수 있는 다른 권장 도구/패키지가 있습니까? 감사 해요.

.js 만 사용하면 빌드 시 .ts 파일을 참조하더라도 제대로 작동합니다.

빠른 답변 감사합니다. tsconfig.json에서 이미 경로 옵션을 설정했지만 여전히 Ctrl+클릭으로 탐색할 수 없습니다.

이것은 tsconfig.json의 내 경로 옵션입니다.

"paths": {
            "*": ["www/node_modules/*"],
            "@modules/*": ["www/node_modules/*"],
            "@root/*": ["www/*"]
        }

.js 만 사용하면 빌드 시 .ts 파일을 참조하더라도 제대로 작동합니다.

수천 개의 수입품이 있을 때 이것은 매우 비실용적입니다.

" .js 만 사용"의 문제는 TypeScript가 .mjs 파일을 내보내면 프로그램이 작동하지 않는다는 것입니다. 이것은 결국 브라우저에서 작동하는 _또는_ NodeJS에서 작동하는 TypeScript를 작성하는 상황에 이르게 됨을 의미합니다. 더 이상 두 가지 모두에서 작동하는 TypeScript를 작성할 수 없습니다.

나는 여기서 주장하는 것이 "TypeScript의 잘못이 아니라 브라우저와 NodeJS가 갈라지는 것"이라고 생각합니다.

Node 13.2는 .js 확장자를 잘 지원합니다.

@justinfagnani ES 모듈용? NodeJS는 확장자가 .mjs 인 경우에만 ES 모듈을 로드할 것이라고 생각했습니다. 그렇지 않으면 파일이 CommonJS로 처리되었나요?

이 전체 스레드가 약간 잘못 안내되어 있다고 생각합니다. 파일 확장자를 명시적으로 작성하면 이 전체 문제가 해결됩니다. JavaScript 파일을 가져오는 경우 .js 확장자를 작성하십시오. TypeScript 파일을 가져오는 경우 .ts 확장자를 작성하십시오. 이것은 표준에서 허용되며 TypeScript 컴파일러는 이를 모두 동등하게 잘 이해합니다. 유일한 문제는 컴파일러가 .ts 확장자가 오류라고 명시한다는 것입니다. 이것은 순수한 변환에 영향을 미치지 않지만 유형 오류일 뿐입니다. TypeScript는 우리가 TypeScript로 작성하기 때문에 분명히 .ts 파일 확장자가 유효하기 때문에 이것을 수정해야 합니다. 이 문제를 해결하기 위해 Deno.js에는 VS Code 확장이 있습니다. https://marketplace.visualstudio.com/items?itemName=justjavac.vscode-deno

WebAssembly의 출현으로 웹 애플리케이션은 점점 더 많은 파일 형식을 가져오기 시작할 것입니다. .wasm, .js, .ts, .rs, .c 등의 파일을 가져오는 경우 명시적으로 명시하는 것이 점점 더 중요해질 것입니다.

내가 작성한 스크립트를 실제로 사용한 사람이 있습니까?

https://github.com/microsoft/TypeScript/issues/16577#issuecomment -310426634

그렇다면 어떤 피드백?

@QuantumInformation 귀하의 스크립트를 사용하지 않았지만 제가 작성한 TypeScript 변환기 플러그인은 기본적으로 동일한 작업을 수행합니다. 😊 https://github.com/Zoltu/typescript-transformer-append-js-extension/

우선, 나는 typescript가 그것을 구현하도록 다시 시도하지 않을 것입니다. 이해합니다. 당신은 그렇게하지 않을 것입니다.
하지만 댓글을 읽고 궁금합니다. .js 를 경로에 추가하면 모든 문제가 해결될 것이라고 말하는 모든 사람들 - 정말 타사 패키지를 사용하지 않습니까? node_modules에 있는 내용을 수정하는 가져오기에 확장을 어떻게 추가합니까?

@MicahZoltu 오 멋지다

무슨 뜻이에요? 경로를 사용하는 경우 node_modules에서 가져오는 파일의 파일 확장자를 명시적으로 작성합니다. 그러나 어쨌든 그것은 일반적으로 벌거 벗은 수입품이 아니겠습니까?

상대 경로를 지정하면 베어가 아닙니다. 그러나 가져오는 패키지의 내부 가져오기에 대해 이야기하고 있습니다. 예를 들어 rxjs를 살펴보세요.

@Draccoz 나는 import { ... } from './foo' 와 같은 TypeScript를 작성한 다음 NPM 패키지로 게시하면 사용자가 ES 모듈을 대상으로 하는 경우에도 해당 라이브러리를 브라우저에서 직접 사용할 수 없다는 것이 요점이라고 생각합니다. 여기서 마이크로소프트의 주장은 패키지가 브라우저에서 작동할 것이라는 기대와 함께 그러한 코드를 배포하는 경우 패키지가 잘못되었다는 것입니다.

node_modules에 있는 파일의 확장자를 작성합니다. JavaScript 파일인 경우 import * as stuff from 'rxjs/path/to/file.js'; , TypeScript 파일을 배포한 경우 import * as stuff from 'rxjs/path/to/file.ts'; 입니다. 내가 틀리지 않으면 이것은 지금 작동합니다.

@lastmjs 예, 하지만 rxjs/path/to/file.ts 에 import foo from './bar' $가 포함되어 있으면 어떻게 될까요? 파일은 타사 라이브러리이므로 수정할 수 없으므로 변경할 수 없습니다.

이것이 우리가 모든 곳에서 명시적 확장을 사용하도록 밀어붙여야 하는 이유입니다. 하지만 네 요점은 알겠습니다. 내 도구(https://github.com/lastmjs/zwitterion)는 확장자가 없는 파일에 대한 임시 해결책으로 이 다시 작성을 수행합니다.

네, 제 요점은 바로 그 점입니다. 확장 기능을 추가하는 것만으로는 우리가 수정할 수 없는 타사 라이브러리를 수정할 수 없으므로 해결 방법이 없습니다.
나는 Microsoft 요점도 얻었으므로 더 이상 미루지 않을 것입니다(이 문제를 열어 두는 것은 패키지 유지 관리자가 TS가 이 문제를 해결하기를 기다리는 대신 빌드를 조정하는 것을 차단하는 불필요한 희망을 준다는 사실을 제외하고), 빌드 도구로 typescript만 있고 다른 종속성은 없는 것이 좋습니다.

네, 하지만 분명히 희망은 여전히 ​​많은 사람들에게 좋은 것입니다

그럼에도 불구하고 그 의견을 통해 몇 번이나 구현되지 않을 것이라고 언급했는데 왜 계속 열어 두는가?

누군가가 './foo'에서 import { ... }와 같은 TypeScript를 작성한 다음 NPM 패키지로 게시하는 경우

많은 사람들이 컴파일되지 않은 TS를 NPM 패키지로 게시하고 있습니까? 내 자신의 내부 사용을 위해 이것을 찾고 있었습니다. 저는 프로젝트 간에 공유되는 공통 코드 라이브러리를 만들고 있으며 NPM이 패키지를 패키징하는 합리적인 방법이라고 생각했습니다. 우리 팀은 독점적으로 TS로 이동했기 때문에 deps를 컴파일하지 않아도 되어서 기쁩니다. 그러나 가장 일반적인 사용 사례는 별도의 타이핑으로 JS에 패키지를 빌드한 다음 modules 또는 main 를 JS로 가리키고 types 를 타이핑하는 것 같습니다.

컴파일되지 않은 TS를 NPM에 게시하는 규칙이 있습니까? 그렇다면 어딘가에 문서화되어 있습니까? 이것이 원래 문제에서 OT를 떠돌고 있다는 것을 알지만 "타사 TypeScript"(패키지)가 지원되는 사용 사례/목표인지 알아야 하기 때문에 답변과 관련이 있다고 생각합니다.

@thw0rted 명확하지 않아 죄송합니다.

...누군가 import { ... } from './foo' 와 같은 TypeScript를 작성한 다음 오늘날 TSC를 사용하여 이를 JS로 변환하고 해당 JS를 NPM 패키지로 게시하면...

구현되지 않으면 지금 문제를 종료하도록 MS에 맡기겠습니다.

아, 이제 알았다. 예, ( target: ES2018 사용) 트랜스파일할 때 방출된 JS는 import 문에서 확장을 생략하지만 소비자가 webpack/babel을 통해 모든 것을 입력하고 누락된 확장을 채워야 하기 때문에 저에게 효과적입니다. 나를위한. 이제 속도를 낼 수 있습니다. 내 "패키지"가 먼저 webpack을 통한 여행 없이는 브라우저에서 기본적으로 작동하지 않을 것이라는 생각조차 하지 못했습니다.

네, 어렵습니다.

@thw0rted webpack/babel을 사용하지 않으므로 상자에서 .js를 해결하는 것이 문제입니다.
일부 솔루션/해결 방법은 기본 확인 소스 에 대해 웹 서버를 구성하는 것입니다.

다른 사람들이 말한 것을 반복한다면 미안하지만 이것은 내가 매일 처리하는 일이므로 요청하지 않은 2센트 중 또 다른 것을 던지고 싶습니다.

TypeScript가 특정 환경(Node.js, Webpack 등)을 수용할 필요는 없다는 것을 알고 있지만 사실 특별히 구성하지 않는 한 확장이 항상 필요한 환경이 많이 있으므로 저는 ' 무시해야 한다고 생각합니다. 가져오기는 더 이상 Node의 플래그 뒤에 있지 않으며 가져오기 경로는 웹의 URL 경로 이름과 일치해야 합니다. URL 끝에 .js 가 있어야 하는 기술적인 필요성은 없지만 이것이 사실상의 표준입니다.

Microsoft의 훌륭한 사람들이 파일 확장자를 기본값으로 사용하지 않기를 정말로 원한다면 나는 그것에 대해 논쟁하지 않을 것입니다. 당신은 아마도 나보다 똑똑할 것입니다. 그러나 동일한 파일의 다른 가져오기를 기반으로 확장이 필요한지 여부를 유추하는 대신 프로젝트 전체에서 설정하여 Intellisense 자동 완성에서 처음으로 작동하도록 할 수 있다면 확실히 더 행복할 것입니다. 파일에 가져오기가 추가되었습니다!

그동안 이 문제를 해결하는 VSCode 플러그인을 아는 사람이 있습니까? eslint에 가져오기/확장 을 추가하는 것이 이 문제를 처리하기 위해 내가 할 수 있는 최선입니다.

현재 .js 확장자가 없는 import 행을 작성한 다음 sed 를 사용하여 출력 파일에 .js 확장자를 추가합니다.
https://github.com/yoursunny/NDNts/blob/9f50fcec245b33c7649fa815bbb3dd404eee160e/mk/build.sh#L12 -L14
출력 파일이 수정된 후 더 이상 일치하지 않기 때문에 프로덕션 빌드 중에 SourceMaps를 삭제해야 합니다.

ts-jest 를 깨기 때문에 .ts 소스 파일에 .js 확장자를 쓸 수 없습니다.
컴파일된 .js 파일에서 Jest를 실행할 수 있지만 Coveralls 가 손상됩니다.

@yoursunny 예, sed는 생성된 js 파일에서 문자열을 교체하기 위해 변형(저도 사용했지만 importmap 파일 매핑으로 구성할 수 있는 구성 때문에 파일 내 교체를 선호함)이지만 냄새가 좋지 않습니다 =) 확장을 추가하는 것은 변환 플러그인이 있는 ttypescript에 유용한 기능/옵션이 될 것입니다(예: @MicahZoltu 의 typescript-transform-paths ).

@richardkazuomiller 이 부분은 사실이 아닙니다:

Microsoft의 좋은 사람들이 파일 확장자를 기본으로 하지 않으려는 경우

TypeScript 전용:

1. 노드 요구 스타일 모듈 확인을 허용합니다(파일 확장자가 필요한 노드 가져오기 스타일 확인을 허용하려면 이를 확장해야 함).
2. 동일한 컴파일 단위에서 .js 파일이 컴파일러에서 생성되기 전에도 .js/.d.ts 쌍으로 확인합니다.
3. 가져오기 지정자를 _전혀_ 수정하지 않습니다.

따라서 이 모든 것에 대한 해결책은 단순히 .js 확장자를 가진 .js 파일을 가져오는 것입니다. TypeScript는 올바른 .ts 파일로 해석되고 가져오기 지정자를 수정하지 않으므로 브라우저와 Node >= 13.2에서만 작동합니다.

@yoursunny ts-jest 에 대해 버그를 신고했습니까? 그들은 여기에서 사실상의 TypeScript 표준에서 벗어나고 있습니다. 또한 .js 파일의 소스 맵을 활용할 수 없는 경우 작업복의 버그처럼 보입니다.

ts-jest 에 대한 버그를 신고하셨습니까? 그들은 여기에서 사실상의 TypeScript 표준에서 벗어나고 있습니다.

아니요, ts-jest 해상도가 어떻게 작동하는지 완전히 이해하지 못하기 때문입니다.

또한 .js 파일의 소스 맵을 활용할 수 없는 경우 작업복의 버그처럼 보입니다.

Coveralls는 내 빌드 프로세스에서 lcov 보고서를 받은 다음 GitHub에 커밋된 파일을 사용하여 코드 적용 범위를 표시합니다.
출력 .js 파일을 GitHub에 커밋하지 않습니다. .js 파일에서 단위 테스트를 실행하면 lcov 보고서는 GitHub에 없는 .js 파일을 참조합니다.
따라서 작업복은 원본 파일을 찾을 수 없습니다. 커버리지 백분율을 표시하지만 커버되지 않은 라인은 표시할 수 없습니다.

새로운 시대가 도래했습니다!

새로 출시된 Node.js v13과 모든 주요 브라우저는 기본 ES 모듈을 기본적으로 지원하며 TypeScript가 이러한 환경을 간단한 방법으로 지원하면 좋을 것입니다.

가장 기본적인 사용 사례(단순한 정적 파일 서버를 통해 제공되는 웹 사이트)에 대한 가장 간단한 솔루션은 "appendJsExtension": true 또는 이와 유사한 새 컴파일러 옵션을 추가하는 것입니다.

@mjbvz 닫은 VS Code 저장소의 문제는 약간 다릅니다. 자동 완성을 사용하여 import 문을 자동으로 추가하는 것입니다. VS Code가 이것을 할 때 .js 확장 없이 import 문을 추가하고 런타임 오류가 발생할 때까지 이것을 간과하기 쉽습니다.

그러나 TypeScript가 "appendJsExtension": true 또는 이와 유사한 옵션을 추가하면 크게 문제가 되지 않으며 소스에 .js 없이 TS 코드를 작성할 수 있습니다.

VS Code 플러그인에 자동 완성된 가져오기 문에서 .js 확장 자동 추가를 활성화/비활성화하는 옵션이 있어야 합니까?

@mjbvz VS Code/Intellisense 문제는 관련이 있지만 속임수로 마감해서는 안 됩니다. 이 문제가 결국 WONTFIX로 종료되면 실제로 VS Code 문제의 중요성이 높아집니다.

간과된 한 가지 점을 보고 있으며 JS 확장이 특수한 경우 솔루션이 이 문제를 해결하는 방법을 이해하지 못하고 있습니다. ESM의 경우 확장이 특별한 상태가 아니며 서버가 다음을 사용하여 브라우저에 제공하는 한 확장이 없는 파일도 완전히 괜찮습니다. 적절한 텍스트/자바스크립트 MIME 유형. 이는 다음과 같은 코드를 의미합니다.

import something from './javascript-code.png';
import something2 from './javascript-code2.js';
import something3 from './javascript-code3.ts';

확장자에 관계없이 파일에 JavaScript 코드가 포함되어 있고 JavaScript MIME 유형으로 브라우저에 제공되는 한 모두 유효합니다.

TypeScript는 JavaScript의 type-safe 상위 집합이어야 하므로 위와 같은 가져오기를 허용하는 방법이 보이지 않습니다. 코드가 유효한 JavaScript이고 TypeScript가 이를 허용하지 않으면 더 이상 안전한 상위 집합이 되기 때문입니다. 자바스크립트, 맞나요?

따라서 JS 확장이 암시되거나 허용되는 유일한 솔루션은 이것을 잘라낼 수 없다고 생각합니까? 또한 TS 및 DTS 확장 IMO도 특별한 경우가 아닐 수 있습니다. 일반적으로 그렇지는 않지만 TypeScript 코드가 아닌 JavaScript 코드를 포함할 수 있고 ESM에 관한 한 전혀 문제 없이 브라우저에 서버를 보낼 수 있기 때문입니다. , 올바른 MIME 유형으로 제공되는 경우

이 전면에서 내가 놓치고 있는 것이 있습니까? TypeScript가 코드 가져오기에서 임의(누락 포함) 확장에 대한 지원을 구현하지 않을 수 있습니까? 그리고 TypeScript가 file.ts 및 file 를 감안할 때 모듈 가져오기에서 TS 확장을 계속 가정할 수 있습니까? (확장자 없음) 충돌이 발생합니까?

웹 및 서비스 작업자는 ES 모듈 가져오기/내보내기에 대한 지원도 받고 있습니다.

나는 @trusktr 의 아이디어를 컴파일러 옵션으로 구현하려는 아이디어를 전적으로 지지하고 지지합니다. 웹팩이나 롤업 같은 번들러를 없애고 싶은 것은 아닙니다. 하지만 이런 기능이 번들러를 설정하는 데 드는 많은 번거로움과 시간을 없앨 것이라고 믿습니다. 원하는 것은 단순히 Typescript 프로젝트를 복잡한 과정을 거치거나 어색한 해결 방법을 사용하지 않고 컴파일하는 것뿐입니다.

이것을 Typescript 컴파일러의 옵션으로 고려하십시오. <3

모든 종류의 모듈 시스템을 사용하여 webpack 또는 --outFile 없이 브라우저에서 컴파일된 개별 js 파일을 실행할 수 있는 방법을 아는 사람이 있습니까?

내 문제는 이것이다: 내가 작업하고 있는 상당히 큰 TypeScript 프로젝트는 ts-loader 를 사용하여 번들된 js 파일로 webpack으로 컴파일하는 데 약 35초가 걸립니다.
이것을 최적화할 수 있는 유일한 방법은 컴파일 시간을 20초로 줄이는 transpileOnly 를 사용하는 것이지만 여전히 느리고 유형 검사가 느슨합니다.
webpack 제거 outFile을 사용하여 약 14초에 도달할 수 있지만 여전히 너무 느립니다. incremental 를 사용해도 아무런 차이가 없었습니다.

몇 초의 컴파일 시간을 얻을 수 있는 유일한 방법은 1ts 파일당 1개의 js 파일을 내보내고 incremental 플래그를 사용하는 것이었습니다. 이 경우 ts가 실제로 변경된 파일만 감지하고 컴파일한다고 상상합니다. 문제는 내가 시도한 모듈 대상(system, amd, es6)의 브라우저에서 이것을 실행할 수 없다는 것입니다.
tsconfig.json paths 매핑을 사용하고 있고 컴파일된 js 파일에서 내가 받는 오류는 대부분 해당 별칭을 해결할 수 없는 것과 관련이 있습니다.

이것을 달성하는 방법이 있습니까?

@andrewvarga 현재 컴파일된 모든 TypeScript를 단일 파일로 묶거나 컴파일하지 않고 브라우저에서 직접 실행합니다. 가장 쉬운 방법은 다음과 같습니다.

1. TypeScript 파일의 모든 가져오기에 .js 확장자가 있는지 확인하십시오.
2. 필요한 경우 종속성에 대한 npm 패키지 이름 가져오기를 해결하는 개발 서버를 실행합니다. es-dev-server 는 내가 아는 가장 간단한 것입니다.
3. tsc --watch 실행(모듈이 tsconfig에서 esnext 인지 확인)

그게 다야 TypeScript에서 가져오기용 .js 확장자를 작성하면 브라우저용 파일을 수정하기 위해 다른 도구가 필요하지 않습니다.

@justinfagnani 친구, 가장 중요한 정보를 잊었습니다. 유형은 jsdoc 형식이어야 합니다. 기본 JavaScript를 통한 모든 유형 스크립트 추상화는 파서를 실패하게 만듭니다.

@Draccoz tsc 는 TypeScript가 아닌 JavaScript를 출력합니다.

@andrewvarga 번들링 없이 트랜스파일하는 가장 간단한 방법은 Zwitterion 프로젝트입니다. 정적 파일 서버를 대체하도록 설계되었으므로 개발 방식을 변경할 필요가 없습니다. 스크립트 요소에서도 명시적 파일 확장명(JavaScript의 경우 .js 및 TypeScript의 경우 .ts)을 사용하여 가져오고 내보낼 수 있습니다. 매우 성능이 좋으며 파일이 변경될 때 캐싱 및 자동 다시 로드를 수행합니다. 정적 분석(유형 오류)을 위해 편집기에 의존해야 합니다.

@andrewvarga 저는 https://github.com/Zoltu/typescript-transformer-append-js-extension/ 을 사용하고 모든 최신 브라우저(새 IE인 Safari 제외)에서 로드되는 기본 ES 모듈을 대상으로 합니다.

런타임 NPM 종속성이 상당히 제한된 경우 번들링 없이 es-modules-shim을 사용하여 로드할 수 있습니다. 이 모든 것이 함께 작동하는 것을 보여주는 내가 만든 반응 템플릿을 볼 수 있습니다. https://github.com/Zoltu/react-es2015-template

@MicahZoltu Safari는 ES 모듈을 지원합니다. 사실 caniuse와 개인적인 경험을 바탕으로 알고 있습니다: https://caniuse.com/#search =modules

@justinfagnani awww 죄송합니다. "컴파일된 TypeScript" 부분을 놓쳤습니다. jsdoc typescript에 대해 말씀하시는 줄 알았습니다.

다양한 팁 감사합니다!

내가 찾은 것은 webpack에 hard-source-webpack-plugin npm 모듈을 사용하고 ts-loader 옵션에 transpileOnly: true 를 사용하면 빌드 시간이 약 4-5초로 단축됩니다.
이것은 물론 typescript 오류를 무시하므로 빌드, 브라우저에서 시도하고 잠재적인 오류에 대해 IDE에 의존하는 빠른 반복에만 유용하지만 개발 중에 매우 유용하다고 생각합니다.

TS 오류와 빠른 컴파일을 모두 얻으려면 여전히 브라우저에서 모듈을 실행하는 것이 유일한 방법이라고 생각하지만 가져오기 맵 및 js 확장에 대한 지원이 부족하여 어렵게 되었습니다.
@justinfagnani @MicahZoltu 감사합니다. 해당 옵션을 시도해 보겠습니다. 일반적으로 npm 모듈을 하나 더 사용하는 것을 피하는 것을 선호하지만 불가피해 보입니다.

systemjs를 사용하여 작동시키려고 했지만 가져오기 맵이 막혔습니다.

@andrewvarga importmap을 사용하여 가벼운 예제 로 SystemJ를 시도할 수 있습니다.
내 무거운 예제 - systemjs 및 esm 대안을 시도 할 수도 있지만 esm importmaps는 기본에서 지원되지 않으며 모듈을 수동으로 해결해야합니다 (gulp-replace) 또는 es-module-shims 를 시도 할 수 있습니다.

따라서 tsc 를 유일한 컴파일러로 사용하는 경우 esnext 또는 es2015 를 모듈 유형으로 타겟팅합니다. 내 브라우저에서 직접 출력을 사용할 수 있는 방법이 있습니까?

https://github.com/alshdavid-sandbox/typescript-only-compiler

이 스레드의 나머지 부분을 올바르게 이해했다면 이 줄 을 from "./module.js" 로 변경하면 Typescript가 코드를 완벽하게 컴파일할 수 있을 것입니다. 그러면 컴파일된 index.js 에 유효한 ES6 가져오기 문이 있고 모두 작동해야 합니다.

ES 가져오기 방법을 모르거나 신경 쓰지 않는 라이브러리를 가져오지 않는 한 그렇습니다.

파일 경로를 가져오기 위해 .js 를 추가하는 Gulp용 플러그인을 만들었습니다. (또한 보너스 ts 경로 해상도).

나는 Gulp를 사용했는데, 본질적으로 간단한 후처리 단계를 tsc 컴파일러(감시 모드와 일반 모드 모두)에 첨부할 수 있는 다른 작업 실행자를 알지 못하기 때문입니다. Webpack과 롤업은 모두 독점적으로 번들로 제공되며 es 모듈을 내보내고 싶습니다.

작동하지만 전체를 재건하는 것처럼 보이므로 보는 것이 느립니다.

https://github.com/alshdavid-sandbox/typescript-only-compiler/tree/gulp

노드 팀이 확장 없는 가져오기에 반대하기로 결정함에 따라 이것은 더욱 중요해지고 있습니다.
https://github.com/nodejs/modules/issues/444

확장 없는 가져오기에 대해서도 결정된 가져오기 맵 추가
https://github.com/WICG/import-maps/issues/194

브라우저나 노드에서 typescript로 컴파일된 es 모듈을 사용하려면 typescript로 확장을 추가해야 합니까? (내부 모듈의 경우) 외부 모듈의 경우 수동으로? @weswigham

@chyzwar 다시 말하지만 TypeScript 소스에 .js 확장을 작성하면 컴파일된 출력에 올바른 확장이 포함되고 모듈이 브라우저와 Node.js에서 작동합니다. 추가 변환 도구나 tsc 가 필요하지 않습니다.

개발자가 다음을 수행하는 것이 더 간단합니다. TypeScript 소스 파일인 경우 .ts 확장자를 작성합니다. JavaScript 소스 파일인 경우 .js 확장자를 작성하십시오. 또한 브라우저에서 올바르게 컴파일 및 실행됩니다(.ts에는 애플리케이션/자바스크립트 MIME 유형이 필요함). 확장자는 소스 파일 형식과 일치해야 합니다. tsc 및 ES 모듈은 이를 처리할 수 있습니다(최소한 브라우저의 ES 모듈, Node.js도 동일하게 따르기를 바랍니다)

@justinfagnani tsc 는 이에 대해 상당히 만족하며 여기에서 "우리 문제가 아닙니다"라고 말하는 것이 공평하지만 무엇이 옳은지에 대한 합의가 없는 것 같습니다.

tsc, vscode, webpack 및 ts-node 사이에서 이제 막 기본적으로 제공되는 표준(현재 사용 가능한 브라우저 및 노드)에 대해 잘 동의할 수 없습니다.

실시예 1

최신 자바 스크립트 패키지를 작성하고 typescript로 작성하고 emascript 모듈로 배포할 유형을 제거하고 싶습니다(가져오기 및 내보내기 문 유지).

실시예 2

저는 vscode의 모듈을 사용하여 정적 웹사이트를 구축 중입니다. 기본적으로 각 첫 번째 가져오기에 대해 확장 없이 자동 가져오기가 수행되며 이를 수동으로 조정해야 합니다.

이러한 경우 tsc는 이를 처리할 수 있으며 전체 타이핑으로 typescript에서 es 모듈 배포를 소비하는 것을 지원하는 설명자 파일을 따로 내보낼 수도 있습니다(굉장합니다).

그러나 소스에 대해 테스트 코드를 실행하려면 ts-node를 사용할 수 있지만 여기서는 ts-node가 만족스럽지 않습니다.

유사하게, tsc, vscode 및 webpack이 다음을 수행하도록 진화했다는 사실:

1. 확장자가 없는 vscode 자동 가져오기
2. tsc는 ts 파일을 의미하는 것처럼 가져오기를 js 파일로 다시 작성합니다.
3. webpack은 여기에서 검색할 기본 확장에 대해 다양한 마법을 수행합니다.

네 가지 구현(chrome, firefox, safari, node)이 모두 가져오기 경로가 파일로 직접 확인할 수 있는 것을 가리켜야 한다고 예상하기 때문에 이제 의문을 제기해야 하는 모든 것입니다.

가져오기에 .js 를 추가하는 것은 확실한 해결책이 아니라 임시 해결 방법이어야 합니다. 뭔가 있으면 해킹 같은 느낌이 듭니다. 컴파일러를 속이는 방법. 그리고 컴파일러를 능가하려는 시도는 imho를 따르는 끔찍한 이데올로기입니다. Typescript를 처음 접하는 사람들에게 이것이 얼마나 혼란스러울지 상상할 수 있을 뿐입니다. Javascript 개발자가 _better_ 코드를 작성하는 데 도움이 되는 언어입니다.

이미 많은 사람들이 언급했듯이 가져오기에 .js를 추가하면 TypeScript가 이를 출력하고 모든 것이 (적어도 코드 내에서) 작동합니다. 브라우저에서 작동하지 않기 때문에 tsc에서 확장을 추가해야 하는 이유는 TypeScript에 개발자에 의해 발생하는 런타임 오류를 수정하도록 요청하는 것과 같습니다. 하지만 개발자가 직접 수정할 수 없는 이유는 무엇입니까?
오해하지 마세요. 저는 tsc가 유일한 개발자 종속성이기를 원하지만 어떤 일은 일어나지 않고 꿈으로 남을 것입니다.

나는 tsc가 나의 유일한 dev 의존성이기를 원하지만 어떤 일은 일어나지 않고 꿈으로 남을 것입니다.

Typescript 팀의 일부를 포함하여 #3469에서 몇 년에 걸쳐 거의 동일한 댓글을 수십 번 보았을 것입니다. "유형 검사기입니다. 한 가지 일을 잘해야 합니다. 전체 도구 모음을 대체할 것으로 기대하지 마세요..." 3년이 걸렸지만 여전히 빌드 모드를 추가했습니다. 올바른 방향.

Webpack과 롤업은 모두 독점적으로 번들로 제공되며 es 모듈을 내보내고 싶습니다.

@alshdavid Rollup은 출력 형식을 esm 로 설정하고 preserveModules 를 true 로 설정하면 작동할 수 있습니다. https://rollupjs.org/guide/en/#preservemodules

아마도 "확장 없는" 가져오기는 브라우저가 작동하는 방식과 호환되지 않는 원죄였습니다.

이제 소스 코드를 수정하고 .js 확장을 포함할 때입니다. 오늘 소스 코드에 .js 확장을 추가하면 모든 것이 작동합니다. 브라우저가 만족스럽고 typescript가 불가지론적이며, 번들러는 신경 쓰지 않는다

그래서 아마도 extensionless는 우리의 오래된 도구가 보완했던 소스 코드의 결함이었을 것입니다.

typescript 소스 코드에서 가져오기에 .js 확장자를 작성하는 것은 완전히 넌센스입니다. 작동 중이며 출력의 확장자를 유지하지만 VSCode 또는 사용 중인 편집기의 ESLint 규칙(또는 TypeScript)에서 "파일을 확인할 수 없음" 오류로 인해 실패할 수 있습니다. 해당 typescript 소스 코드에 대해 테스트할 때는 말할 것도 없습니다. 그런 다음 테스트 도구는 그 멍청한 행동에 대해서도 알아야 합니다. 파일을 해결할 수 없다는 오류가 발생할 것이라고 거의 확신합니다.

기본 예

src/index.ts
src/foo.ts
test/index.ts

src/foo.ts

export default (a: number) => a + 100;

src/index.ts

// okay, editor (without ESLint) doesn't report error here
import foo from './foo.js';

export default () => {
  console.log(foo(123));
}

테스트/인덱스.ts

// errm... ts or js ext?! .ts should be the one that make sense
// and that's how the testing too will expect it to be, otherwise will throw
// but then it will detect some weird `.js` ext in the source files...
// which again won't be able to resolve... complete bullshit. 
import main from '../src/index.ts';
import foo from '../src/foo.ts';

test('some boolshit', () => {
  main();
});

test('about foo', () => {
  foo(20);
});

"헛소리" 사용에 대해 유감스럽게 생각하지만 그것이 사실입니다.

컴파일러가 가져오기에서 확장자( .ts )를 보고 .js 로 변환하는 기본 옵션을 구현하는 것은 그리 어렵지 않다고 생각합니다. 이다). 확장이 없을 때 확장을 유지하지 마십시오(준전류 동작?).

typescript 소스 코드의 imports에서 .js 확장자를 작성하는 것은 완전히 말도 안되는 소리입니다. 작동 중이며 출력의 확장자를 유지하지만 VSCode 또는 사용 중인 편집기의 ESLint 규칙(또는 TypeScript)에서 "파일을 확인할 수 없음" 오류로 인해 실패할 수 있습니다.

이것은 사실이 아닙니다. ESLint, TypeScript, VS Code 및 기타 모든 TypeScript 관련 도구는 이 방법으로 _그냥 작동_했습니다. 이것은 해킹이 아니며 매우 합리적인 근거가 있습니다. 가져오는 파일은 실제로 .js 파일이며 가져온 파일이 로컬 파일의 일부이기 때문에 확장자가 변경되어서는 안 됩니다. 프로젝트 또는 타사 패키지의 일부로 미리 컴파일됩니다.

다시 말하지만, 저는 모든 TypeScript 코드를 이런 방식으로 작성하고 이 스레드에서 제기된 모든 문제를 해결합니다. 출력은 브라우저와 Node.js에서 훌륭하게 작동합니다. 헛소리가 아니라 _오늘_ 작동합니다.

아니, 그렇지 않다. 최소한 출력 디렉토리가 dist 또는 build 또는 lib 등인 가장 일반적인 경우입니다. 컴파일된 파일은 동일한 디렉토리에 있지 않으며 절대 존재하지 않습니다. 거기 ( src/ ) - 테스트 중이거나 편집기에서 코딩 중이 아닙니다.

위의 src/index.ts ./foo.js 를 갖고/보고 가져오는 것은 나에게 아무런 의미가 없습니다. 물론 js/json 파일을 가져오려는 의도가 아니라면 완전히 괜찮습니다. 그러나 다른 typescript 소스 파일( ./foo.ts )을 의미할 때 ./foo.js 를 작성하는 것은... 잔인합니다. 그것은 오해의 소지가 있고 혼란스럽고 확실히 잘못된 것입니다.

Jest로 위의 test/index.ts 를 실행하면 ./foo.ts 만 있기 때문에 ./foo.js 를 찾거나 해결할 수 없다는 오류와 함께 실패할 것이라고 거의 확신합니다.

모든 것을 제쳐두고 .js 확장자는 허용되지만 .ts $ 확장자는 허용되지 않는 이유는 무엇입니까(ts report error in the editor)? 그것은 기본적이고 단순하며 어리석은 모순입니다. TypeScript의 다른 많은 "그냥 때문에" 문제.

실제로 .js 확장자로 끝나는 것이 가능한데 왜 이 문제의 이름이 그런 식으로 명명되었는지에 대한 논리를 잃어버렸습니다. 나는 문제가 완전히 반대라고 생각합니다 .ts (3.7+ 기준)로 끝날 수 없다는 것입니다.

수입에서 .ts 확장이 완전히 금지 된 이유는 무엇입니까?!

그리고 명확히 합시다. 나는 개발 시간과 경험에 대해 이야기하고 있습니다. 컴파일된 출력에서 .js 확장자를 보존할 수 있는 이유와 보고 오류 없이 .ts 파일의 가져오기에 .js $ 확장자를 추가할 수 있는 이유를 알았습니다. 괜찮습니다.

TypeScript는 JavaScript의 상위 집합이지만 JavaScript는 아닙니다. JavaScript는 TypeScript의 컴파일 대상입니다.

이를 염두에 두고 TS가 JS로 컴파일된다는 사실에도 불구하고 TypeScript 코드가 완전히 독립적인 방식으로 작동할 것으로 예상합니다.

.ts 파일을 가져오려고 할 때 .js 작성은 대상 컴파일 유형에 대한 지식을 가정하고 컴파일 대상이 항상 JavaScript라고 가정합니다.

TypeScript를 웹 어셈블리 바이너리로 컴파일하거나 Deno 또는 ts-node와 같은 대체 런타임을 사용하여 TypeScript 코드를 실행하면 어떻게 될까요?

.js 로 끝나는 import 문은 이러한 컨텍스트에서 의미가 없습니다.

내 가져오기 경로에 .ts 를 입력해야 하거나 TypeScript 소스 파일을 가정하는 지정된 확장자가 없는 것이 좋습니다.

typescript가 흐름과 같은 구문 설탕이 아닌 자체 확장을 발명했다는 것은 슬픈 일입니다.

@phaux 소스 파일과 dist 파일이 다른 폴더에 있더라도 동일한 확장명으로 혼합하는 프로젝트에서는 작업하고 싶지 않습니다. 다른 폴더에 살고 있기 때문에 모든 파일의 이름을 index.js 로 지정하는 것과 같습니다.

이 문제(TypeScript보다 큼)는 Visual Studio Code의 IntelliSense가 웹 브라우저 및 노드에서 작동하는 것을 차단하는 것으로 보입니다. 이 문제는 가져오기 지정자에 전체(상대) 파일 경로가 필요합니다. 이것이 없으면 생성된 import 문은 WebPack 및 TypeScript 자체와 같은 트랜스파일러 및 번들러에서만 작동합니다.

VSCode 팀의 응답은 자동 가져오기 제안을 제공하는 코드로 확장을 추가해야 한다는 것이었습니다. TypeScript Language Server(여기서 논의된 tsc 아님)라고 생각합니다.

실제로 아는 사람이 VSCode가 TypeScript Language Server에서 자동 가져오기 제안을 받는다는 것을 확인(또는 수정)할 수 있습니까?

상황은 약간 복잡하고 미묘한 차이가 있으므로 ".js" 확장이 처음에는 많은 사람들의 우아한 직관과 이상에 반대되지만, typescript가 승인된 브라우저 표준 및 출하된 구현에서 많이 벗어나는 것은 현명하지 않고 혼란스러울 수 있습니다.

그래서 아마도 우리는 현재의 패러다임을 다음과 같이 생각합니다:
typescript 가져오기는 런타임 에 가져오는 것을 설명합니다 . 즉, 가져오기는 fetch 호출 및 나머지와 같이 "src"가 아닌 "dist" 디렉토리에서 실행됩니다. 이 아이디어를 허용할 수 있다면 나머지는 간단하고 일관된

node가 commonjs에 대해 수행하는 것처럼 확장 없는 가져오기에 typescript가 맹목적으로 ".js"를 첨부하는 것은 확실히 나쁜 생각인 것 같습니다 (node ​​esm 지원에는 오늘날 typescript와 동일한 방식으로 ".js"가 필요하다는 점에 유의할 가치가 있습니다) – ".js"를 맹목적으로 첨부 진정한 확장자가 없는 자바스크립트 파일 또는 css 또는 json과 같은 다른 파일 유형을 가져오는 것과 같은 새로운 문제를 만들 것입니다. 확장자를 의미 있게 만들고 특별한 구문 분석 논리를 필요로 하여 브라우저와 typescript 의미론 사이에 뚜렷한 차이를 생성합니다. 그리고 우리는 분명히 그렇게 하지 않을 것입니다. fetch 를 다시 작성하는 것은 같은 방식으로 호출하므로 import 가 비슷하게 유지되어야 합니까?

그러나 나는 궁금합니다. typescript가 ".t" 확장자를 ".js"로 변환하는 것이 상대적으로 무해한가요?

물론 그렇게 하면 ".t" 확장자를 가진 자바스크립트 파일을 가져올 수 없습니다. 하지만 이것이 우리가 견딜 수 있는 약간 의 펑키한 마법일 수도 있습니다. 다른 한편으로는 개발자가 배우고 이해해야 하는 브라우저와 타이프스크립트 시맨틱 사이의 펑키하고 마법 같은 특이한 차이점입니다(분명히 이상한 문제를 만들어 냄). 그래서 제 본능은 현재 상태를 그대로 두는 것입니다.

반면에 있는 그대로 유지하면 마법이 단순히 ".js" 가져오기를 해당 ".ts" 소스 파일과 연결해야 하는 typescript로 재배치됩니다. 브라우저 의미를 짓밟는 대신 typescript 내부에 있는 마법을 담다

🥃 추격전

@rconnamacher , @TomasHubelbauer

이 문제(TypeScript보다 큼)는 Visual Studio Code의 IntelliSense가 웹 브라우저 및 노드에서 작동하는 것을 차단하는 것으로 보입니다. 이 문제는 가져오기 지정자에 전체(상대) 파일 경로가 필요합니다. 이것이 없으면 생성된 import 문은 WebPack 및 TypeScript 자체와 같은 트랜스파일러 및 번들러에서만 작동합니다.

여기에 약간의 혼란이 있다고 생각합니다. 오늘날 브라우저와 노드에서 작동하고 esm 또는 commonjs에서 작동하는 vscode 및 intellisense와 함께 잘 작동하는 typescript 라이브러리 또는 앱을 만드는 것이 매우 가능합니다. 진정한 보편적인 솔루션은 오늘날 가능합니다.

저는 renraku , cynic , redcrypto , 권위주의 를 보여주는 소수의 공개 라이브러리에서 작업했습니다.

이메일을 보내주시면 자세히 설명해 드리겠습니다.

:웨이브: 추격

또 다른 요점은 액세스하는 파일에 혼란을 초래한다는 것입니다. .js 및 .ts 파일이 나란히 있는 경우 모듈 확인 후 tsc 가 무엇을 보는지 이미 모호합니다.

/folder
  a.ts
  a.js
  index.ts

index.ts 인 경우 moduleResolution: 'node' 사용 시

// points to a.ts
import * as a from './a` 

// points to a.ts
import * as a from './a.js` 

// compiler emits error
import * as a from './a.ts` 

.js 및 .ts 파일이 나란히 있는 경우 모듈 확인 후 tsc가 확인하는 내용이 이미 모호합니다.

알겠습니다. 하지만 a.js 가 a.ts 의 트랜스파일 버전이 아닌 경우 무언가가 치명적으로 잘못된 것이며 TypeScript의 잘못이 아닙니다.

@thw0rted 단일 JS 번들 파일로 컴파일하는 경우 TypeScript는 입력 TypeScript 파일에 대해 JS 대응 파일을 생성하지 않고 단일 번들 파일만 생성합니다. 이 경우 JS 파일과 동일한 이름의 TS 파일이 어떤 식으로든 일치하지 않는 것은 완전히 합법적입니다.

"불법"은 아니지만 그것이 좋은 생각이라는 의미는 아닙니다. 실제로 이것을 원하는 위치에 대한 구체적인 예가 있습니까?

번들러, 로더 없이 최신 브라우저에서 직접 사용할 수 있는 JavaScript를 내보내는 방식으로 TypeScript를 사용하는 것이 좋습니다.

예로서:
https://github.com/alshdavid/tsc-website

그러나 나는 문제의 고통을 느낀다. TypeScript 팀은 모듈 확인을 구현하고 싶지 않습니다. TypeScript 컴파일러가 컴파일 시간에 paths 를 실제 상대 경로로 변환할 수 없는 것과 같은 이유입니다.

가져오기를 .ts 에서 .js 로 변환하거나 확장 없이 가져오기에 .js 를 추가하는 것은 TypeScript 팀이 모듈 확인을 구현하고 범위를 벗어남을 의미합니다.

이에 대한 솔루션은 TypeScript 팀이 확장을 도입하여 이러한 것들을 구현할 수 있는 방법을 제공하는 것입니다.

이에 대한 솔루션은 TypeScript 팀이 확장을 도입하여 이러한 것들을 구현할 수 있는 방법을 제공하는 것입니다.

그들은 단지 tsc 를 통해 노출되지 않습니다(컴파일러의 프로그래밍 방식 호출을 통해서만). 운 좋게도 누군가가 구성을 통해 확장을 지원한다는 점을 제외하고 tsc 와 같이 _정확하게_ 작동하는 핵심 컴파일러 주위에 래퍼를 구축했습니다. 이 tsc 래퍼를 사용하면 https://github.com/Zoltu/typescript-transformer-append-js-extension/ 과 같은 확장을 사용하여 .js 확장을 자동으로 추가할 수 있습니다.

@alshdavid GitHub의 예제는 가져오기에 .js 확장만 포함하면 번들러가 없는 브라우저에서 작동합니다. 나는 그것을 고치기 위해 PR을 제출했다.

@alshdavid 내 샘플 프로젝트 (현대 및 IE11 with SystemJS용 esm)에 관심이 있을 수 있습니다.
하지만 esm 모듈을 수동으로 해결해야 합니다 =(

내 모든 import 에 .js 를 넣는 것은 원칙적으로 문제가 없지만 불행히도 일부 도구와의 상호 작용이 좋지 않습니다. 예를 들어, ts-node 초크: https://github.com/TypeStrong/ts-node/issues/783. .js 확장자를 내보내는 TypeScript 또는 번역을 수행하기 위해 TypeScript 소스를 사용하는 모든 도구에 대한 책임이 누구에게 있는지에 대한 명확한 합의가 없는 것 같습니다. 그리고 모든 사람이 책임을 지는 한 사용자는 문서화되지 않은 플러그인이나 상호 운용성 비호환성을 해결하기 위해 불편한 서비스 작업자로 고통받고 있습니다.

이에 대한 업데이트가 있습니까? Webpack과 같은 외부 모듈 로더나 번들러 없이는 오늘날 TypeScript를 정상적으로 사용할 수 없다는 것이 솔직히 믿기지 않습니다. 이것은 나에게 너무 이상하고 또한 실망스럽게 보입니다. TypeScript가 완전히 작동하도록 하기 위해 외부 모듈을 사용해야 하는 경우 시작해야 합니다.

내 Electron 앱에서 이것을 사용하려고 하는데 웹 번들러를 사용할 이유가 없고 필요하지 않은 경우 외부 모듈 로더를 설치하지 않기를 원합니다. 그러나 이것은 나를 화나게 만들고 있습니다. 기본 TypeScript + Electron 설정을 수행할 수조차 없었지만 둘 다 어디에서나 최고의 솔루션으로 칭찬받았습니다. 그건 미친 짓이야, 솔직히 말해서. 내가 뭔가를 놓치고 있지만 적절한 솔루션을 찾을 수 없다는 것은 좌절감을 주는 것 이상인지 모르겠습니다.

그리고 정말 제가 아니라면 왜 이 문제가 3년 동안 수정되지 않았는지 이해가 되지 않습니다...

최근에 typescript 자습서를 완료한 다음 일부 ts 파일을 만들려고 할 때 이 문제를 해결했습니다. 저는 이 js-ts 세계에 완전히 익숙하지 않으므로 잘못된 것이 있거나 오해의 소지가 있거나 잘못된 정보가 있는 경우 저를 용서해 주십시오.

내가 한 일은 수입하는 동안

방금 ts 파일에 .js 확장자를 넣은 다음 Intellisense를 확인했을 때 tsc를 사용하여 변환했을 때도 작동했습니다. 생성된 출력 파일에 .js 확장명도 추가했습니다.

다음은 내가 한 일입니다.
tsc -p tsconfig.json

{
"컴파일러 옵션": {
//"모듈": "amd",
"모듈": "es6",
"대상": "es6",
"noImplicitAny": 거짓,
"댓글 제거": 참,
"preserveConstEnums": 거짓,
//"outFile": "js",
"outDir": "js",
"sourceMap": 거짓
},
"포함": [
"testscript.ts"
]
}

그것이 나를 위해 일했지만.

내 의심은 가져올 svgwrapper.js가 없기 때문에
왜/ 어떻게 작동했나요? (나는 그것이 확장을 고려하지 않는다고 가정합니다)

참고용으로 스크린샷을 첨부합니다.

@yogeshjog 이것이 정확히 tsc 의 작동 방식과 작동 방식입니다. 생성될 파일 이름으로 모듈을 가져옵니다. 가져온 모듈이 원래 .ts 파일로 작성되었는지 아니면 .d.ts / .js 쌍으로 작성되었는지 여부는 가져오기 모듈에서 관찰할 수 없어야 합니다.

@yogeshjog 이것이 정확히 tsc 의 작동 방식과 작동 방식입니다. 생성될 파일 이름으로 모듈을 가져옵니다. 가져온 모듈이 원래 .ts 파일로 작성되었는지 아니면 .d.ts / .js 쌍으로 작성되었는지 여부는 가져오기 모듈에서 관찰할 수 없어야 합니다.

감사 해요! @justinfagnani 설명을 위해 👍

생성될 파일 이름으로 모듈을 가져옵니다.

그러나 TypeScript는 ECMAScript에 따라 허용되지 않는 확장자를 생략할 수도 있습니다. VSCode에서 가장 짜증나는 기능인 자동 가져오기 기능을 사용할 때 확장자를 생략하기도 합니다. 일부 JS를 작성하고 TS는 괜찮다고 말한 다음 런타임에 충돌합니다.

그러나 TypeScript는 확장자를 생략할 수도 있습니다.

노드 확인을 사용할 때. tsconfig는 최소한 이것에 대해 경고하는 다른 해상도 모드를 허용하도록 설정되어 있지만, 팀이 더 많은 모드를 추가하기 전에 기본 모듈 지원이 정착되도록 내버려 둔 것으로 알고 있습니다.

ECMAScript에 따라 허용되지 않습니다.

ECMAScript는 가져오기 지정자에 대해 아무 말도 하지 않습니다. 그것은 HTML 및 Node.js와 같은 호스트 환경에 달려 있습니다. TypeScript는 모듈을 로드할 때 노드 해석을 지원하고 컴파일러 _input_이 아닌 컴파일러 _output_에 대해 해석을 해석합니다. 이런 식으로 지정자는 컴파일 후에 작동하며 컴파일된 모듈을 가져오려는 시도 여부에 관계없이 작동합니다.

TypeScript는 경로 검색을 수행하여 './foo' info './foo.js' , './foo' 가 유효합니다. 그러나 노드 확인은 './foo.ts' 을 './foo.js' 로 바꾸지 않으므로 './foo.ts' 는 유효하지 않습니다.

그러나 그것은 노드 해상도 내에 있습니다. HTML 또는 Node의 기본 모듈 지원과 같은 다른 환경을 사용하려는 경우 TypeScript와 호스트는 무엇이 유효한지에 대해 동의하지 않습니다.

이제 TypeScript가 다른 해상도 설정을 추가할 수 있을 만큼 네이티브 모듈 지원이 해결되기를 바랍니다.

@leontepe 번들러 /로더가 필요하지 않습니다. https://github.com/Zoltu/typescript-transformer-append-js-extension/ (내가 선호하는 솔루션)을 사용하거나 모든 가져오기 문에 .js 를 추가할 수 있습니다(주의: 이렇게 하면 ts-node 에서 코드가 실패하도록 합니다.

@leontepe 번들러 /로더가 필요하지 않습니다. https://github.com/Zoltu/typescript-transformer-append-js-extension/ (내가 선호하는 솔루션)을 사용하거나 모든 가져오기 문에 .js 를 추가할 수 있습니다(주의: 이렇게 하면 ts-node 에서 코드가 실패하도록 합니다.

@MicahZoltu 글쎄요, 감사합니다. 하지만 '즉시' 작동하지 않는다는 사실에 여전히 실망스럽습니다. @phaux 가 말했듯이 VSCode는 사용자에게 확장 없이 import 문을 만들 것을 제안하며 이는 단순히 런타임에 작동하지 않습니다. 나는 여기서 TypeScript 팀의 능력에 대해 심각하게 의문을 제기합니다. 하지만 누가 알겠습니까...

편집: 이 시점에서 JavaScript + Babel용 TypeScript를 삭제하는 것을 진지하게 고려합니다.

나는 Electron 애플리케이션을 작성하지 않았지만 고정된 순서로 여러 가지를 시도하는 가져오기를 해결하려고 시도하는 알고리즘이 있는 노드 스타일 해결을 할 가능성이 있습니까? 모든 소스가 로컬 리소스에서 로드된다는 점을 감안하면 괜찮은 것 같습니다...

TS에 새로운 모듈 해상도를 추가할 때가 되었나요? Node.js는 이제 기본 ESM을 지원하지만 상대 경로에 명시적인 확장이 없으면 --experimental-specifier-resolution=node 플래그를 사용해야 하므로 다소 짜증이 납니다. Deno와 브라우저도 있습니다. 이상적으로는 다음과 같은 것이 있어야 합니다.
tsconfig.json:

{
    "compilerOptions": {
        "moduleResolution": "explicit",
        "strict": true
    }
}

그런 다음 Typescript:

import foo from './foo.ts'; // no ts(2691) here

자바스크립트로 컴파일:

import foo from './foo.js';

"strict": true는 많은 작업을 의미합니다!
2020, 여전히 수정되지 않은, 우스꽝스러운.

이 문제가 우리 팀도 차단하고 있다고 말하면서 소리를 지르십시오 😢

우리는 기본 모듈로 빌드되고 노드 및 웹팩에서도 소비 가능한 단일 소스를 가질 수 있기를 정말로 원합니다. TS 코드의 가져오기에 .js를 수동으로 넣으면 Webpack에 문제가 있는 것 같습니다. 그러나 가져오기에 .ts 파일 확장자를 넣으면 일종의 웹팩이 작동하도록 할 수 있지만 물론 typescript는 불평합니다. 파일 확장자가 없으면 기본 모듈이 없습니다. 따라서 브라우저와 번들러를 만족시키는 조합은 없는 것 같습니다. 가져오기에 .t를 쓰고 출력에서 ​​.js가 되도록 하면 문제가 해결될 것입니다. @ evg656 과 같은 것이 작동해야 할 것 같습니다.

@EisenbergEffect 이에 대해 WebPack에 대해 버그가 제출되었습니까? 정말 일반 tsc에서 발산하는 WebPack 문제처럼 들립니다.

@justinfagnani 문제가 webpak, ts-loader 또는 다른 곳에 있는지 잘 모르겠습니다. 최적의 빌드 설정을 구현하기 위해 많은 시간을 보냈지만 모든 확인란을 선택하는 솔루션을 찾지 못했습니다. 커스텀 트랜스포머나 빌드 후 단계로 이를 수행하는 방법 이 있을 수 있지만 다운스트림 개발자에게 부정적인 영향을 미칠 수 있으므로 비표준 설정을 채택하는 것을 꺼립니다.

@EisenbergEffect WebPack의 TypeScript 로더가 tsc .js 확장자를 통해 TypeScript 파일을 가져올 수 없다면 버그입니다. 말했듯이 이 동작은 WebPack 및 tsc 로 동일한 소스 빌드를 방지합니다.

TS에 새로운 모듈 해상도를 추가할 때가 되었나요? Node.js는 이제 기본 ESM을 지원하지만 상대 경로에 명시적인 확장이 없으면 --experimental-specifier-resolution=node 플래그를 사용해야 하므로 다소 짜증이 납니다. Deno와 브라우저도 있습니다. 이상적으로는 다음과 같은 것이 있어야 합니다.
tsconfig.json:

{
    "compilerOptions": {
        "moduleResolution": "explicit",
        "strict": true
    }
}

그런 다음 Typescript:

import foo from './foo.ts'; // no ts(2691) here

자바스크립트로 컴파일:

import foo from './foo.js';

사람들(예를 들어, 저)은 Node.js, Deno 및 웹에서 동시에 하나의 코드가 작동하도록 하고 싶어합니다. 이것이 TypeScript/JavaScript 프로그래밍의 큰 이정표가 될 것이라고 생각합니다.

vscode를 사용 중이고 임시 솔루션이 필요한 경우 이것을 settings.json 에 추가하면 문제가 해결되는 것 같습니다.

"typescript.preferences.importModuleSpecifierEnding": "js"

.js 를 가져오기 경로에 추가합니다(이는 오류 없이 src의 *.ts 파일을 해결하지만 트랜스파일할 때 .js 를 유지함). 번들러 없이 tsc 를 사용할 때 유용합니다.

우리가 tsc 솔루션을 기다리는 동안 이에 대한 낮은 기술 수정 사항은

1. 모든 소스 파일을 임시 폴더에 복사
2. 빌드 전에 가져오기 및 내보내기에 대한 확장을 제거하십시오.

다른 사람들이 사용할 수 있도록 이 한 줄짜리를 공유하고 싶었습니다. src/ 폴더를 tmp/에 복사하고 거기에서 파일을 변경합니다.

npx shx cp -r ./src/ ./tmp/ && npx rexreplace "(^§s*?(?:import|export).*?from§s+?(['\"]).*?)§.ts§2" €1€2 './tmp/**/*.{ts,js,tsx,jsx}'

package.json의 빌드 스크립트의 일부로( yarn add --dev shx rexreplace 수행 후) 다음과 같이 보일 수 있습니다.

"scripts":{
  "build": "yarn build-esm && yarn build-tsc",
  "buil-esm": "...Whatever you normally do...",
  "build-tsc": "shx mkdir -p tmp && shx cp -r ./src/* ./tmp && rexreplace \"(^§s*?(?:import|export).*?from§s+?(['\\\"]).*?)§.ts§2\" €1€2 './tmp/**/*.{ts,js,tsx,jsx}' && tsc src/index.ts && shx rm -r ./tmp"
}

Jest를 행복하게 유지하기 위해 현재 TypeScript 소스의 가져오기 경로에서 .js 를 유지하고 있습니다.
그런 다음 .js 를 추가하는 사후 처리 단계가 있습니다.
이 방법에서는 소스 맵이 지원되지 않습니다.

tsc -b tsconfig-solution.json -w --listEmittedFiles \
  | node mk/build-post.js

build-post.js 사후 처리 스크립트는 다음을 수행합니다.

상대 경로의 import 및 export 에 .js 추가

예를 들어,

export { X } from "./first";
import { Y } from "./second";

된다

export { X } from "./first.js";
import { Y } from "./second.js";

어디에서나 index.ts 를 사용하지 않고 대신 Deno 규칙에 따라 mod.ts 를 사용합니다. 따라서 /index.js 를 추가하는 경우를 고려할 필요가 없습니다.

CommonJS 패키지에 대해 import 를 require 로 변경

내 코드는 노드 ^12.17 및 ^14.1에서 모듈 모드로 실행됩니다. ES 모듈만 게시합니다.
그러나 많은 종속성에는 "main" 필드에 CommonJS가 있습니다.
따라서 NodeJS 내장 모듈을 제외하고 CommonJS로 변경해야 합니다.

예를 들어,

import { Server as WsServer } from "ws";

된다

import { createRequire } from "module";
const require = createRequire(import.meta.url);
const { __importDefault } = require("tslib");

const { Server: WsServer } = require("ws");

그러나 webpack은 이러한 require 에 만족하지 않으므로 다음을 사용해야 합니다.

/// #if false
import { createRequire } from "module";
const require = createRequire(import.meta.url);
const { __importDefault } = require("tslib");
/// #endif

/// #if false
const { Server: WsServer } = require("ws");
/*
/// #else
import { Server as WsServer } from "ws";
/// #endif
/// #if false
*/
/// #endif

webpack에서 내 프로젝트를 가져오는 모든 패키지는 ifdef-loader 를 사용해야 하며, 그러면 webpack은 원래 import 행을 보게 됩니다.

저희도 이에 피해를 입고 있는데, 신고된 지 3년이 넘도록 수정되지 않는지 이해가 되지 않습니다.
VSCode 특정 설정이 작동하지 않도록 WebStorm을 사용하고 있습니다.
출력을 수정하기 위해 별도의 스크립트를 사용하는 것은 어리석은 일입니다.
이것은 타사 도구를 사용하지 않고도 작동해야 합니다.

+1

이것은 asp.net core 3.1 웹 사이트를 사용하는 해결 방법입니다(낮은 버전에서 작동할 수 있음).
startup.cs에서:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseRouting();

            var rewriteOptions = new RewriteOptions();
            rewriteOptions.AddRewrite(@"^js/(.+)", "js/$1.js", skipRemainingRules: true);

            app.UseRewriter(rewriteOptions);

            app.UseStaticFiles();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapGet("/", async context =>
                {
                    await context.Response.WriteAsync("Hello World!");
                });
            });
        }

재작성 미들웨어는 /js 폴더를 대상으로 하는 모든 요청에 ​​확장자 ".js"를 추가합니다.
경고: 여기서 미들웨어의 순서가 중요합니다. UseStaticFiles는 UseRewriter 뒤에 배치되어야 합니다. 그렇지 않으면 작동하지 않습니다.

여기 있는 모든 사람들과 마찬가지로 저는 즉시 사용 가능한 솔루션을 선호하지만 그때까지는...

TS에 새로운 모듈 해상도를 추가할 때가 되었나요? Node.js는 이제 기본 ESM을 지원하지만 상대 경로에 명시적인 확장이 없으면 --experimental-specifier-resolution=node 플래그를 사용해야 하므로 다소 짜증이 납니다. Deno와 브라우저도 있습니다. 이상적으로는 다음과 같은 것이 있어야 합니다.
tsconfig.json:

{
    "compilerOptions": {
        "moduleResolution": "explicit",
        "strict": true
    }
}

그런 다음 Typescript:

import foo from './foo.ts'; // no ts(2691) here

자바스크립트로 컴파일:

import foo from './foo.js';

node/file-extension-in-import 규칙을 eslint-plugin-node 에서 import 문에 수동으로 추가하고 TypeScript에서 "moduleResolution": "node" 에 확장을 수동으로 추가한다는 아이디어로 linting 구성에 설정했습니다. 구성하고 내가 볼 수있는 것은 ts(2691) 입니다.

@evg656 이 말한 것이 구현할만한 가치가 있기를 바랍니다.

이것이 여전히 문제라는 것이 믿기지 않습니다.

당신이 사용할 때
"baseUrl": ".", "paths": { "/*": ["./*"] },

다음과 같이 절대 모듈 가져오기를 수행할 수 있습니다.
`"/hey/connection"에서 ws 가져오기;

그러나 ".js" 확장자를 추가할 때 갑자기 컴파일러는 더 이상 connection.ts 선언을 찾지 않고 다음과 같이 말합니다.

Could not find a declaration file for module '/hey/connection'. '/home/tobi/Documents/JITcom/Code/Libs/Test_Browser/hey/connection.js' implicitly has an 'any' type.

상대 경로를 사용하면 모두 잘 작동합니다.

고쳐주세요

나는 또한 이것에 대한 수정을 원합니다.

감사합니다.

이게 아직도 이슈가 되고 있다는게 웃기네요! :00

마침내 TypeScript로 전환하기로 결정했고 이것이 내가 처음 직면한 문제 중 하나였습니다. 그것은 Node의 기본 구현에서 모듈 확인을 깨고 확장자가 없는 이름을 받아들이는 데 더 유연한 것처럼 보이는 esm 패키지를 사용하거나 (이상하게) 가져오기 경로에서 .js 확장자를 사용하여 해결할 수 있었습니다. 가져오기가 .ts 또는 .tsx 파일을 참조하는 경우에도 내 .ts 파일 내부에 있습니다. TypeScript 컴파일러가 이를 수락하는 이유는 확실하지 않지만 적어도 빌드 출력에는 .js 확장자가 포함됩니다. 끔찍하게 해키 솔루션.

나는 요즘 클라이언트 측에서 typescript를 많이 사용하지도 않고 내 코드 품질에 너무 많은 영향을 미치지 않고 일을 더 간단하게 만들었습니다. 아마도 JavaScript는 선택적인 유형의 원포인트를 가질 것이고 이 문제는 더 이상 중요하지 않을 것입니다.

Jest와 Webpack을 행복하게 만들기 위해 가져오기 라인의 확장을 생략합니다.
컴파일할 때 tsc --listEmittedFiles 를 호출하고 출력을 후처리 스크립트로 파이프합니다. 이 스크립트는 .js 확장을 추가하여 Node(모듈 모드에서)를 만족스럽게 만듭니다.
https://github.com/yoursunny/NDNts/blob/fa6b2eb68a9f32a6a2e24e5475275f803236b8f8/mk/build-post.js

@kj

(이상하게도) 가져오기가 .ts 또는 .tsx 파일을 참조하는 경우에도 내 .ts 파일 내부의 가져오기 경로에서 .js 확장자를 사용합니다. TypeScript 컴파일러가 이를 수락하는 이유는 확실하지 않지만 적어도 빌드 출력에는 .js 확장자가 포함됩니다. 끔찍하게 해키 솔루션.

이상하지 않고 확실히 해킹되지 않으며 브라우저 및 노드 기본 모듈 해상도와 완벽하게 작동합니다.

가져오는 리소스는 .js 파일입니다. 유형은 .ts 파일 또는 .d.ts 파일에 있을 수 있습니다. .d.ts 파일은 .js 모듈의 형제일 필요도 없으며 .d.ts 파일과 .js 파일 사이에 1:1 관계가 필요하지 않습니다.

.js 모듈을 가져오는 것은 tsc가 선택할 수 있는 가장 안정적이고 안정적인 옵션입니다. 그렇지 않으면 유형을 가져오고 tsc가 실제 모듈 경로에 유형을 다시 작성하는 올바른 방법을 모르는 경우가 있습니다.

@justinfagnani 아, 말이 되는 것 같아요. TypeScript가 여기서 하는 모든 것이 해키(나는 그런 주장을 할 수 있는 위치에 있지 않음)라는 의미는 아닙니다. 단지 내가 하고 있는 일이 일반적이지 않을 수도 있다고 느꼈습니다. 그런데 제가 잘못 생각하고 있었던 것 같아요. 모듈을 가져오는 것은 TypeScript가 아니라 빌드 출력을 평가하는 것입니다(또는 제가 오해하고 있는 것입니까)? 이 경우 왜 이런 식으로 작동하는지 알 수 있습니다.

가져오는 리소스는 .js 파일입니다.

여기서 빌드된 모듈을 말씀하시는 건가요? 소스 디렉토리의 .js 파일이 아니라 .ts 모듈의 빌드 버전입니까?

모듈 경로에 .ts 또는 .tsx 확장자를 명시적으로 지정하면 출력이 .js를 대체하지 않을까요?

@kj 무슨 일이 일어나고 있는지에 대한 오해가있을 수 있다고 생각합니다. 코드를 컴파일하지 않고 .ts 확장자를 지정하면 ts 파일을 참조합니다. 그러나 tsc를 사용하여 컴파일하면 ts 파일의 내용이 현재 환경(노드 또는 브라우저)에서 실행 가능한 js 파일로 변환됩니다.

@mkay581 을 이해하지만 foo.ts 파일에 다음 줄이 있다고 가정합니다.

import { Component } from './Component.js';

내가 언급하는 'Component.js'는 실제로 파일 시스템의 'Component.tsx'입니다(TypeScript가 이것을 파일의 최종 트랜스파일 버전을 참조하는 것으로 이해하지 않는 한 .js 파일은 없습니다?), 아직 TypeScript는 이것을 잘 받아들이고 동일한 가져오기 줄이 출력에 표시됩니다(Node 또는 브라우저에서 작동하는 .js 확장명 사용).

기존 TypeScript 방식(AFAIK)은 다음과 같이 확장자 없이 가져오기 라인을 지정하는 것입니다.

import { Component } from './Component';

트랜스파일된 .js 파일의 가져오기 라인에 './Component'에 .js 확장자가 포함되어 있지 않다는 점을 제외하고는 분명히 잘 컴파일됩니다. t 확실히 읽으십시오).

반면에 소스 파일의 실제 파일 이름으로 줄을 지정하면:

import { Component } from './Component.tsx';

그러면 TypeScript는 경로를 인식하지 못하고 파일 확장자 없이 가져오기 행을 시도해야 한다고 제안합니다(기억하면 지금은 컴퓨터에 있지 않습니다).

따라서 첫 번째 예제는 TypeScript를 작성 중일 때 .ts 또는 .tsx 확장자로 가져올 수 있을 것으로 예상하지만 확장자가 없는 경로만 허용합니다(이는 ES 모듈 시스템의 다른 구현과 상이함) 또는 그러한 소스 파일이 없기 때문에 출력 파일만 참조할 수 있는 .js 확장자를 사용합니다.

@justinfagnani

가져오는 리소스는 .js 파일입니다.

나는 tsc가 어떻게 작동하는지 모르지만 그것은 나에게 옳게 들리지 않습니다. 코드를 작성할 때 아직 .js 파일이 없습니다. 그것을 만드는 것은 컴파일러의 일입니다.

TS는 JS 위에서 추상화 계층 역할을 하며 .js 파일은 컴파일 단계의 출력입니다. 그 특정 확장으로 거기에 있다는 것을 믿으면 IMO라는 추상화를 깨는 것 같습니다.

다시 말해, C 또는 C++를 사용할 때 #include .o 파일을 코드에 포함하지 않고 .h 또는 최대 .c 또는 .cpp .

나는 Typescript에서 이 동작에 대한 합리적인 설명을 기꺼이 받아들일 수 있지만, 내가 뭔가를 놓치고 있지 않는 한 이것은 아닌 것 같습니다.

@kj

이상하지 않고 확실히 해킹되지 않습니다.

동의하지 않습니다. 나에게 그것은 이상하고 해키의 바로 그 정의입니다. 😛 여기서 하는 작업은 가상 파일을 참조하는 것입니다. 존재가 보장되지 않는 파일입니다. (예: 코드 번들링, AssemblyScript 또는 deno 사용) 출력 형식을 가정하고 있습니다. 그러나 불가지론적인 코드(예: 타사 모듈)를 작성할 때 이는 가정할 _위험한_ 것입니다.

@borfast @frzi 네, 기본적으로 제가 느꼈던 점입니다. 이 부분에 불편함을 느끼는 사람이 저뿐만이 아니라는 사실을 알게 되어 기쁩니다. TypeScript가 너무 새롭다는 가정을 너무 많이 하지 않으려고 합니다!

@frzi

여기서 하는 일은 가상 파일을 참조하는 것입니다. 존재가 보장되지 않는 파일

가상이 아니라 tsc가 생성할 것임을 알고 있습니다. tsc를 사용할 때 반드시 존재합니다.

그것을 보는 또 다른 방법은 .ts 파일을 가져오면 컴파일 후에 존재하지 않을 파일을 가져오는 것입니다.

코드를 묶을 때

번들러는 tsc 이후에 실행됩니다.

@kj 는 .tsx 파일을 언급했고, 그것들은 내 요점을 더욱 강조합니다. .tsx는 해당 모듈의 컴파일러(_locally_)에 모듈에 JSX가 포함되어 있다는 신호를 보내기 위해서만 존재합니다. 모듈을 가져오는 사람은 파일에 JSX가 있다는 것을 알 필요가 없으며 컴파일 후에 알 수 없습니다. 파일은 .tsx, .ts 및 .js/.d.ts 쌍 간에 원활하게 이식될 수 있습니다.

.ts 파일을 가져온다고 가정해 보겠습니다.

import {Component} from './component.ts';

그런 다음 구성 요소에 JSX를 사용하려고 하므로 이름을 component.tsx로 변경합니다. 모든 가져오기가 실패해야 합니까? .ts에서 .js/.d.ts로 마이그레이션한다고 가정하면 가져오기가 다시 실패해야 합니까?

@borfast

TS는 JS 위에서 추상화 계층 역할을 하며 .js 파일은 컴파일 단계의 출력입니다. 그 특정 확장으로 거기에 있다는 것을 믿으면 IMO라는 추상화를 깨는 것 같습니다.

추상화는 여기에서 암시하는 것만큼 완전하지 않습니다. TS 프로젝트 내부 또는 외부에서 .js 파일을 가져올 수 있습니다. 프로젝트의 모든 위치에 있는 .d.ts 파일을 사용하여 .js 파일에 유형을 추가할 수 있습니다. .js 파일은 컴파일 후 실제입니다. 다른 모든 것은 컴파일러를 도울 뿐입니다.

@justinfagnani 나는 당신이 말하는 것에 대해 약간 잃어 가고 있지만 왜 TypeScript는 .ts 또는 .tsx가 있는 가져오기 경로를 제공하면 해당 모듈에 대한 .js 파일을 생성하고 따라서 출력에서 ​​후자의 확장을 대체해야 합니까?

@justinfagnani

가상이 아니라 tsc _알고_ 생성할 것입니다. tsc를 사용할 때 반드시 존재합니다.

그러나 여기에는 당신이 인정하지 않는 대칭이 함축되어 있습니다.

귀하가 언급한 이 "보증"은 양방향으로 적용됩니다. 당신이 말했듯이 "tsc _knows_ 그것은 [js 파일]을 생성할 것입니다."라고 묻는다면 똑같이 유효한 질문입니다. 컴파일된 js에서 누락되었습니까?”

"tsc가 js 파일을 보장한다"는 사실을 해석하는 것은 양방향입니다.

그래서 나는 @justinfagnani , 당신의 해석이 특정 관점에서 _is_ 유효하다는 데 동의합니다. 그러나 반대 해석은 "그러므로 tsc는 _자신의 지식에 따라 행동하고_ 개발자를 위해 이 프로세스를 수행해야 합니다."입니다. 그리고 처음부터 이 전체 토론에 대해 나를 괴롭히는 것은 이 해석이 거의 조롱을 받을 정도로 _부정적으로_ 받아들여지는 것입니다. 말도 안돼

결국 이 논쟁은 _논리적인 결정이 아니라 미학적 결정에 관한 것입니다. 그리고 내 희망은 미학적 _의견_(논리적 추론이 아님)에 고유한 것처럼 부적절하고 수용적인 목소리가 반대자들에 의해 이 문제에 영향을 미치게 되는 것입니다.

요컨대, OP의 질문이 완벽하게 유효한 해석임을 인정하십시오. 아마도 귀하의 해석과 함께일 것입니다. 거친 논쟁이 ​​필요하지 않습니다.

감사합니다

@justinfagnani

그것을 보는 또 다른 방법은 .ts 파일을 가져오면 컴파일 후에 존재하지 않을 파일을 가져오는 것입니다.

물론 .h 파일이 C 프로그램의 실행 파일과 함께 배포되지 않는 것처럼 그렇지 않습니다. 이것이 바로 요점입니다. 컴파일러에게 컴파일된 파일이 아닌 소스 파일을 포함하도록 지시합니다.

좋아, 이 대화에 스팸이 너무 많아 더 이상 무시할 수 없습니다.
import 문은 typescript의 일부가 아니라 그것을 실행한 JavaScript 환경의 일부입니다. 자, 여기서 키워드는 JavaScript 환경입니다. 이것이 경로를 해결하는 것입니다. 런타임에 .ts 파일을 가져오고 실행하는 단일 앱 을 보여주세요.
TypeScript는 소스 파일 내부에 기본 JavaScript를 허용하기 때문에 .js 확장자를 추가할 수 있습니다. node.js의 브라우저 중 어느 쪽도 .ts 파일을 실행하지 않습니다 ts-node 라도 .ts 파일을 즉석에서 변환하고 결과를 하드 드라이브에 기록하는 대신 메모리에 보관합니다(해키가 전혀 아닙니다. ?).

이제 적절한 tsc 수정은 다음과 같습니다.

• .ts 파일이 있습니다.
• 다른 파일에서 참조
• tsc는 .ts 파일을 .js 파일로 변환합니다.
• 그런 다음 tsc는 .ts .js #$ 파일로 다시 작성합니다(변환 방법을 정확히 알고 있으므로 올바르게 업데이트할 수 있음).

문제: "modern web dev"는 실제 웹 개발이 아니며 node.js 가져오기 방식을 사용하여 확장자(및 전체 파일 경로)를 건너뜁니다. tsc 이제 더 이상 출력이 무엇인지 알 수 없습니다 my-awesome-module/test 가져오기는 node-modules/my-awesome-module 파일 test.js node-modules/my-awesome-module 에서 시작하여 index.js 파일까지 무엇이든 될 수 있습니다. $ node-modules/my-awesome-module 의 test 폴더 내부, ./local-mocks/my-awesome-module/mock.json 와 같은 비 js 파일로 일부 로컬 재작성으로 끝납니다.

여기서 문제가 발생합니다. tsc는 특정 프로젝트에 대한 펑키한 webpack/rollup/super-awesome-new-and-shiny-bundler 구성이 무엇인지 어떻게 알 수 있습니까?

다시: 저는 tsc가 가져오기 경로를 다시 작성하는 것을 찬성하지만 단순한 프로젝트에서만 작동하고 단순한 프로젝트에서만 작동하도록 만드는 것(요즘에는 단순한 프레젠테이션 페이지에서도 과도하게 엔지니어링된 웹팩 구성과 반응하기 때문에 소수입니다)은 가치가 없습니다. 간단한 사용자 정의 작성된 스크립트로 수행할 수 있는 경우 시간을 보내십시오.

다시: 저는 tsc가 가져오기 경로를 다시 작성하는 것을 찬성하지만 단순한 프로젝트에서만 작동하고 단순한 프로젝트에서만 작동하도록 만드는 것(요즘에는 단순한 프레젠테이션 페이지에서도 과도하게 엔지니어링된 웹팩 구성과 반응하기 때문에 소수입니다)은 가치가 없습니다. 간단한 사용자 정의 작성된 스크립트로 수행할 수 있는 경우 시간을 보내십시오.

webpack이 없는 간단한 프로젝트에서 tsc만 있으면 어떻게 하시겠습니까?

나는 모든 사람의 의견을 읽고 있으며 여기에서 typescript 사용에 대한 기대치에 대한 근본적인 불일치인 것 같습니다.

.ts 소스 파일이 .js 파일을 참조할 때 문제는 이미 시작된 것입니다.

Typescript는 .js 파일이 아닌 소스 .ts 파일을 ~run~ 컴파일하도록 빌드되었습니다. 개발자가 프로젝트에서 TypeScript를 사용하려면 _entire_ 프로젝트를 typescript로 변환해야 하며 분리된 .js 파일을 남겨두고 참조하려고 해서는 안 됩니다. 그리고 js 파일의 내용을 Typescript 구문으로 변경할 시간이 없는 경우 js 파일의 이름을 ts 파일로 변경합니다(또는 TS의 경로 매핑을 사용하여 가져오기를 .js 파일로 매핑). 문제 해결됨. :man_shrugging:

편집: "실행"을 "컴파일"로 수정했습니다. 이는 제가 의미한 것이지만 어떻게 다르게 해석되었을 수 있는지 알 수 있습니다.

@mkay581 TypeScript는 JS 파일을 출력하기 위해 아무 것도 실행하지 않았습니다.

@valeriob Simple 프로젝트에는 번들할 필요가 없는 파일이 거의 없을 것입니다. 요즘 브라우저에는 가져오기 기능이 내장되어 있으므로 이를 우회할 필요가 없습니다. 그러면 브라우저에서 탐색 이벤트를 수신 대기한 다음 각 이벤트를 일치하는 경로에 매핑하는 것처럼 간단합니다. 각 경로 는 fetch 로 데이터를 가져올 수 있고 반환되면 컴파일되지 않은 템플릿 엔진으로 렌더링할 수 있습니다. html, HyperHTML 또는 Mustache, Handlebars, Pug 등과 같은 오래된 것). 완료, 멋진 웹팩, 프레임워크 또는 유틸리티 라이브러리가 필요 없습니다. 리스너, regexp, fetch, promise 및 간단한 js 템플릿 엔진만 있으면 됩니다.

@Draccoz 에게 감사드립니다. 이 간단한 시나리오를 작동시키는 방법을 알려주실 수 있습니까? https://github.com/valeriob/Typescript_Non_SPA
JS 라이브러리(예: rxjs)를 참조하는 간단한 .ts 파일이며 html 페이지에서 모듈로 사용하고 싶습니다.

@valeriob 이것은 그렇게 사소하지 않습니다. 대부분의 타사 라이브러리는 ES 모듈과 호환된다고 선언하더라도 브라우저 세계에는 없습니다.
RxJS는 기본 흐름으로 가져올 때 내가 가장 관심이 많았던 것이지만 그들은 스스로 구현하기로 결정하기 전에 이 티켓이 해결되기를 기다립니다(재미...).
내가 설계하고 있던 아키텍처에서 처음에는 모든 가져오기를 수정하는 데 sed를 사용했지만 경로 재작성 기능이 있는 간단한 개발 서버를 사용하기로 마음을 바꿨습니다. 내 개념은 rxjs, typescript 및 lit-html(4개의 폴더 및 ULTRA 빠른 CI 테스트/빌드가 있는 node_modules)을 제외하고 내 앱에 외부 종속성이 없다는 것입니다. TS가 경로를 다시 작성하면 어쨌든 약 90줄의 코드이지만 내 서버가 필요하지 않습니다. 오픈 소스입니다. 링크를 원하는 사람이 있으면 내 프로필에 있는 조직에 문의하거나 확인하세요.

간단한 페이지에 관해서는 url 누르기 -> 데이터 가져오기 -> 표시하기 -> 반복과 같이 실제로 라이브러리가 필요하지 않은 페이지를 참조했습니다.

Js에는 기본 라이브러리가 없기 때문에 Js에서 라이브러리를 사용할 필요가 없다는 것은 순수한 환상입니다.

간단한 시나리오는 내가 연결한 시나리오이며 작동하지 않습니다. 또한 실제 이점도 없이 일을 복잡하게 만들고, 옵션을 매우 제한하고, 개발자가 앱을 작성하는 것보다 도구와 싸우게 만들고, 개발자를 느리게 만드는 미친 웹팩/컴파일 세계에 뛰어들고 싶지 않은 ppl의 가장 일반적인 시나리오입니다. 고리.

많은 정신 체조에서 이 문제가 존재하며 많은 개발자의 생산성에 중요한 문제임을 부인합니다.

그것이 _문제가 되어서는 안 됨_을 설명하는 것은 _문제를 해결_하지 않습니다. 소프트웨어는 사용자의 정신 모델을 따라야 하며 사용자에게 자체 구현 모델을 강요해서는 안 됩니다. (UX 관련)

사용자가 @borfast 에 따라 tsc를 C와 같은 컴파일러로 개념화하는 경우 tsc의 구현 세부 정보가 무엇이든 간에 수용해야 하는 특권 정신 모드입니다.

OP의 질문에는 리포지토리의 다른 모든 문제보다 많은 200개 이상의 엄지손가락이 있습니다.

이 문제는 커뮤니티 투표를 받을 자격이 있습니다. 설문 조사를 시작하는 것을 고려하십시오.

대부분의 사용자가 tsc가 가져오기를 다시 쓰기를 원하면 그것이 정답입니다. 적어도 그것이 사물을 보는 UX 방식입니다.

그보다 훨씬 더 간단합니다. typescript가 언어로서 JavaScript의 상위 집합인 경우 tsc의 출력(단일 출력 파일 스위치가 아닌 경우에도)은 JavaScript 자체에서 소화할 수 있어야 합니다.

@weoreference 여러 환경(node.js, 브라우저), 여러 번들러 구성 가능성(현재, 계획 및 가능한 모든 미래 기능 조사 webpack, 롤업 및 소포 및 기타 번들러) 그렇다면 TypeScript 팀이 귀하의 편에 가득 찰 것이라고 믿습니다.

그렇게 할 의향이 없거나 너무 어렵다고 생각되면 아무도 실제로 설명할 수 없는 기능을 만들도록 요청하지 마세요. "나는 어떻게 하든 상관없지만 이 소를 날게 하세요"와 같습니다...

@Draccoz , 당신은 10Km/h보다 빠르게 운전할 수 있도록 차가 기어를 변속하기를 원하지만, 디자인은 고사하고 기어 트레인이 어떻게 작동하는지 배우도록 제조업체에서 요청한 적이 없다고 확신합니다.

번들러 및 기타 문제에 관해서는 이것이 왜 차단 장치입니까?

봐, 난 그냥 ES 모듈을 사용하고 싶고 모든 Babel과 Webpack의 미친 짓을 다루고 싶지는 않아. 파일 확장자를 .js로 변경하는 선택적 컴파일러 옵션이 될 수 없는 이유는 무엇입니까? 이 동작이 사용자가 설정한 다른 구성 옵션과 충돌하는 경우 자동으로 비활성화되거나 경고/오류가 표시되고 tsc가 실행될 때 컴파일이 중지되어 사용자가 구성을 변경해야 함을 알 수 있습니다.

이게 왜 불가능한지 정말 모르겠습니다.

@Draccoz 안녕하세요 :) 글쎄, 내가 보기에 당신은 두 가지를 묻고 있습니다.

1. 구현 방법

2. 개발자인 내가 tsc에 특정 환경에 대해 특정 방식으로 가져오기 이름을 변경하고 싶다는 신호를 보내는 방법

여기 내 생각이 있습니다.

1. @borfast 의 회신을 참조하십시오. "고차" 답변이지만 간결합니다. :)

2. "renameImports":true와 같은 플래그를 tsc/tsconfig에 전달할 수도 있고 tsc에서 선택하는 다른 신호를 전달할 수도 있습니다. 더 많은 정밀도가 필요한 경우 플래그는 부울이 아니라 다음과 같은 문자열을 취해야 합니다.

standardImportExtension: 'js'

따라서 파일 확장자가 없는 모든 가져오기의 기본값은 .js입니다.

결론:
이 기능은 Q2(가져오기 이름 바꾸기 체계)가 Q1(즉, tsc)에 의해 미리 알려질 필요가 있다고 가정하기 때문에 구현하기 어려운 것처럼 보입니다. 그러나 실제로는 아닙니다. 인간 개발자인 나는 webpack/browsers/ 등이 어떻게 작동하는지 알 필요 없이 이 "세계 지식"을 tsc에 쉽게 제공할 수 있습니다. 이 모든 것이 간단한 플래그입니다.

@borfast 전송은 사용자가 요청한 것이 아니라 제조업체에서 자동차와 함께 제공되었으며 사용자는 새로운 기능에 동의하고 사용하기 시작했습니다. 죄송합니다. 이것은 적절한 주장이 아닙니다. 귀하의 자동차 제조업체 예와 비교할 때 "내 차가 100,000마일 범위와 제트기의 속도에 도달하는 최고 속도의 완전 전기 자동차가 되기를 바랍니다. 나는 그것을 달성하는 방법에 신경 쓰지 않고 그것을 원합니다. 그게 다야 - 기간.
@weoreference 내 질문에 약간의 오해. 나는 tsc가 경로가 가리키는 것을 이해하도록 하는 방법에 대해 묻고 있었습니다. 직접 js 파일인가요? 아니면 내부에 index.ts 가 있는 폴더입니까? 아니면 main 필드를 포함하는 package.json이 있는 모듈입니까? 아니면 esnext 필드? 아니면 표준이 아닌 다른 것이 있습니까? 아니면 webpack에 의해 다시 작성된 경로입니까? 아니면 롤업? 그렇다면 구성은 어디에 있습니까? 다른 번들러일까요? 덜 알려진 일부? 그리고 위 문장에서 내가 생각하지 못한 다른 사용 사례는 무엇입니까?

"renameImports":true와 같은 플래그를 tsc/tsconfig에 전달할 수도 있고 tsc에서 선택하는 다른 신호를 전달할 수도 있습니다.

@weoreference 경로 매핑 으로 이미 이 작업을 수행할 수 없습니까? TSconfig 파일의 paths 옵션은 가져오기 경로를 JS 파일에 매핑하는 제어를 제공합니다. 제가 잘못 해석하고 있다면 죄송합니다.

@Draccoz 답변 감사합니다. 명확히 해주세요.

그리고 위 문장에서 내가 생각하지 못한 다른 사용 사례는 무엇입니까?

예, tsc가 이러한 모든 환경/빌드 도구 조합에 대한 지식을 갖추는 것은 매우 어려울 것입니다.

그러나 tsc는 개발자가 _대부분의_ 사용 사례를 다루는 데 도움이 되는 간단한 유틸리티를 가질 수 있으며 이것이 제가 설명한 "standardImportExtension" 구성 값입니다.

물론 여기에 "보증"의 문제가 있습니다. 이 스레드의 앞부분에서 tsc는 컴파일된 js가 실제로 [일부 환경에서] 실행되도록 "보장"해야 한다고 주장했습니다.

음... 어쩌면 이것은 너무 힘든 약속이었을 것입니다. 실제로 tsc가 js가 [일부 환경에서] 실행되도록 보장하는 것은 매우 어렵습니다. 왜냐하면 방금 설명한 것처럼 현재 js 환경에서 해당 환경을 정의하기가 매우 어렵기 때문입니다.

그러나 @borfast 가 제안한 간단한 플래그 유틸리티는 tsc를 시도하는 새 사용자가 겪는 js 가져오기 오류의 _대부분_을 해결합니다.

귀하가 언급한 고급 사용은 이러한 모든 고려 사항으로 구성됩니다.

직접 js 파일인가요? 아니면 내부에 index.ts가 있는 폴더입니까? 아니면 메인 필드를 보유하고 있는 package.json이 있는 모듈입니까? 아니면 esnext 필드? 아니면 표준이 아닌 다른 것이 있습니까? 아니면 webpack에 의해 다시 작성된 경로입니까? 아니면 롤업? 그렇다면 구성은 어디에 있습니까? 다른 번들러일까요?

— 그 사용법은 실제로 사용자 정의 사용자 스크립트, 번들러 및 기타 도구에 맡길 수 있습니다.

그러나 고급 사용법이 풀기 어렵다고 해서 쉬운 경우를 피해야 하는 것은 아닙니다.

가장 쉬운 경우는 가져오기에 .js 확장자를 추가하는 것입니다. 우리가 해결할 수 있고 해결해야 하는 것.

@weoreference 그래서 나는 당신이 질문을 하고 도움을 주려고 노력했는데 당신이 그 질문을 무시한 것에 대해 반대 투표를 했습니다. 실제로 생산적인 솔루션으로 진행하는 대신 논쟁하고 토론하려는 것처럼 보입니다. 당신은 그렇게 하려는 모든 사람의 시도를 반대했습니다. 이 스레드에 대한 마지막 메시지입니다. 모든 스팸에 대해 사과드립니다. 여러분.

@weoreference 는 @DanielRosenwasser 댓글에서 이 대화의 맨 처음을 살펴보세요. 그는 그들이 그것을 구현하지 않는 이유를 설명합니다("현재"? 쓸모없는 희망 주기). 그의 성명 이후에 typescript의 누구도 이 주제에 대해 더 이상 언급하지 않았습니다. 저에게는 이 토론이 종료되어야 하며 Microsoft는 공식적으로 입장을 밝혀야 합니다. 기간.
참고로 저는 개인적으로 그 기능에 찬성합니다. 많이 단순화할 것입니다. typescript 팀 주장도 이해하면서 희망을 잃었습니다.

@weoreference

가상이 아니라 tsc가 생성할 것임을 알고 있습니다. tsc를 사용할 때 반드시 존재합니다.

그러나 여기에는 당신이 인정하지 않는 대칭이 함축되어 있습니다.

귀하가 언급한 이 "보증"은 양방향으로 적용됩니다. 당신이 말했듯이 "tsc가 [js 파일]을 생성할 것이라는 것을 알고 있습니다."라고 묻는다면 똑같이 유효한 질문입니다. 컴파일된 js에서 누락되었습니까?”

대칭은 실제로 유지되지 않습니다. ".js 확장자 적용"만큼 간단하지 않습니다. tsc는 지정자를 확인하고 다시 작성해야 하며 확인은 유형 선언에 따라 달라질 수 있습니다. TypeScript 및 Babel은 단일 모듈 컴파일 모드(tsc의 경우 isolateModules)를 지원하며 이 경우 JavaScript 대신 유형을 가져오면 tsc는 유형 선언을 로드하여 해당 .js 파일의 위치를 ​​결정해야 합니다. 지정자. 일관성을 유지하고 극단적인 경우가 없도록 하려면 컴파일 전에 존재하거나 현재 프로젝트의 알려진 결과인 .js 파일 가져오기만 지원하는 것이 가장 간단합니다.

@justinfagnani @Draccoz 감사합니다. 네, 알겠습니다.

내 마지막 의견: "어려운 경우를 해결할 수 없다고 해서 쉬운 경우를 해결할 수 없는 것은 아닙니다."

감사합니다

TypeScript가 여기에서 사양에 어긋난다고 가정했지만(그리고 잘못된 JavaScript를 생성함) 가져오기 경로가 파일 이름과 정확히 일치해야 하는 사양 을 어디에서도 찾을 수 없습니다(확장자 포함). 소화하기가 매우 어렵기 때문에 완전히 확신할 수는 없지만 사양에서 'FromClause'의 'ModuleSpecifier'가 'StringLiteral'이어야 한다는 점만 알 수 있습니다. 매우 느슨한 정의처럼 보이지만 ECMAScript가 존재하는 다양한 환경에서 모듈 해석의 유연성을 허용하기 위한 것일 수 있습니다. 아무도 내가 이것을 올바르게 읽고 있는지 확인할 수 있습니까? 이것이 사실이라면 TypeScript가 이를 처리하는 방식에 대한 입장을 완화해야 합니다. 그래도 TypeScript, Node 및 웹 간에 더 많은 상호 운용성이 있는 것을 선호합니다. 현재 상황은 이상적이지 않습니다.

나는 이것을 읽은 후에 이 문제에 이르렀다. 그 문제는 Node의 시스템이 ES 사양으로 인해 작동하는 방식(파일 이름과 엄격하게 일치)으로 작동한다는 인상을 주었지만 이제 내가 잘못 읽었음을 알 수 있습니다(ES 사양을 참조하지 않음). TypeScript도 실제로 '잘못된' 작업을 수행하지 않습니다. 그런 다음 이 문제는 실제로 서로 다른 환경 간의 모듈 해결에 대한 동등하게 유효한 접근 방식 간의 비호환성에 관한 것입니다. 여전히 TypeScript의 주요 대상 환경은 분명히 Node와 웹이고 Node가 이론적으로 접근 방식을 변경할 수 있지만 브라우저가 그럴 가능성은 거의 없다고 생각하므로 여전히 이 문제가 유효하다고 생각합니다.

편집: 모듈 해상도가 '호스트 정의'임을 지정하는 것으로 보이는 사양의 이 섹션이 아닐까 생각합니다.

@kj 관련 사양 텍스트는 HTML 사양에 있습니다. https://html.spec.whatwg.org/multipage/webappapis.html#resolve -a-module-specifier

가져오기 지정자는 전체 URL 또는 절대 또는 상대 경로여야 한다고 말합니다. 지정자가 URL로 구문 분석하지 않거나(일반적으로 http:// 또는 https:// 시작) / , ./ 또는 ../ 시작하는 경우

다른 경로 검색 또는 해결은 수행되지 않습니다. 이는 지정자가 모듈의 전체 URL로 확인되어야 하고 서버에서 요구하는 경우 확장을 포함해야 함을 의미합니다. 서버에는 확장 없는 URL에 대한 응답을 반환하는 옵션이 있습니다.

Node가 모듈에 대해 보다 제한적인 해결 알고리즘을 사용하는 이유는 웹과의 호환성이 향상되어 npm에 게시된 모듈이 브라우저에서 기본적으로 실행하기 위해 추가 도구가 필요하지 않은 것이 더 일반적이기 때문입니다. 패키지 이름으로 가져오기는 여전히 매우 중요한 기능이므로 Node는 이를 지원하지만 Import Maps 제안 (Deno 및 SystemJS가 이미 지원)과 호환되는 것을 목표로 합니다.

.js 확장으로 가져오기에 대한 tsc의 지원은 노드와 웹 브라우저 모두에서 완벽하게 작동합니다. 실제로 추가 도구 없이 문제를 일으키는 것은 확장 없는 가져오기입니다. 일반적으로 패키지 이름에 대한 노드 확인을 지원하는 도구는 클래스 require() 스타일 확인도 사용하고 상대 경로를 확인하고 확장도 추가합니다. 이것이 es-dev-server 가 하는 일입니다.

@justinfagnani 감사합니다. 따라서 적어도 브라우저에서는 서버가 이를 구현하는 방법에 달려 있습니다. 알아두시면 좋습니다. 이것은 여전히 ​​직관적이지 않고 혼란 스럽습니다. 커뮤니티의 이익을 위해 프로젝트간에 더 많은 수렴이 필요하다고 생각하지만 더 이상 그것이 어떻게 보일지 확신하지 못합니다.

편집: 지금은 이것으로 충분할 것입니다(특히 위의 설명을 보면 더 편안합니다).

https://nodejs.org/api/esm.html#esm_customizing_esm_specifier_resolution_algorithm

이 옵션이 TypeScript 문서에서 참조되는지 확실하지 않지만 그렇지 않은 경우 혼동을 피하기 위한 것일 수 있습니다. ' site:typescriptlang.org specifier-resolution' 또는 ' site:staging-typescript.org specifier-resolution'을 검색하는 것 같지 않습니다. 이것은 Node에서 여전히 새로운 기능이므로 그리 놀라운 일은 아닙니다.

@justinfagnani 나는 .js 확장이 대부분의 경우에 작동한다는 데 동의합니다. 단, 누군가가 이에 반대하는 이념적 입장을 취하는 경우(예: https://github.com/TypeStrong/ts-node/issues/783, 당신이 알고 있는).

여기 에서 @quantuminformation 스크립트의 종속성 없는 버전을 만들었습니다. 해당 버전에는 이미 .js 로 끝나지 않는 모듈만 교체하는 정규식이 포함되어 있습니다.

같은 필요

import 문에서 .js 를 사용하여 ESM 호환성을 위한 .js 확장을 달성하는 것이 작동하지 않습니다. TS 파일을 가져오고 확장자를 생략하면 잘 컴파일됩니다. 가져오기에 .js 확장을 추가하면 TS 컴파일러에서 많은 오류(존재하지 않아야 함)가 발생합니다.

이 기능이 개발되지 않는 주된 이유는 다양한 번들러와의 호환성이 어렵거나 불가능하기 때문인 것 같습니다. 하지만 Node.js와 번들러는 ECMAScript에서 모듈에 대한 지원이 없는 상태에서 자체 모듈 방식을 개발했습니다. 일부 사람들이 생각하기에 부적절하다고 생각하는 ESM이 이제 우리에게 있어 앞으로 나아갈 길입니다. ESM 및 웹 구성 요소에서 더 많은 코드가 개발됨에 따라 번들러의 사용이 줄어들고 TS와 ESM 간의 이러한 고충점은 더 많은 마찰을 발생시킵니다. 초기 지원이 버그가 있고 모든 사용 사례를 고려하지 않더라도 지원을 시작할 수 있다면 좋을 것입니다.

더 나은 솔루션이 있을 때까지 이것은 빌드 작업으로 사용할 비 종속성 노드 스크립트입니다.

package.json에서 구성하십시오.

  ..
    "scripts": {
        "build": "node build.js",
   ...

//build.js
import { execSync} from "child_process"
import * as util from "util"
import * as fs from "fs"
import * as path from "path"

//function to recurse dirs finding files
function fromDir(startPath, filter, callback) {

    //console.log('Starting from dir '+startPath+'/');

    if (!fs.existsSync(startPath)) {
        console.log("no dir ", startPath);
        return;
    }

    var files = fs.readdirSync(startPath);
    for (var i = 0; i < files.length; i++) {
        var filename = path.join(startPath, files[i]);
        var stat = fs.lstatSync(filename);
        if (stat.isDirectory()) {
            fromDir(filename, filter, callback); //recurse
        }
        else if (filter.test(filename)) callback(filename);
    };
};

//this add .js to lines like:  import .* from "\.  <-- only imports from ./ or ../ are touched
function addDotJsToLocalImports(filename) {
    var buf = fs.readFileSync(filename);
    let replaced = buf.toString().replace(/(import .* from\s+['"])(?!.*\.js['"])(\..*?)(?=['"])/g, '$1$2.js')
    if (replaced !== buf.toString()) {
        fs.writeFileSync(filename, replaced)
        console.log("fixed imports at "+filename )
    }
}

//------------------------
//---BUILD TASK START 
//------------------------

execSync("npx tsc --build -verbose", { stdio: 'inherit' })

//add .js to generated imports so tsconfig.json module:"ES2020" works with node
//see: https://github.com/microsoft/TypeScript/issues/16577
fromDir("./dist", /\.js$/, addDotJsToLocalImports)

https://github.com/microsoft/TypeScript/issues/16577#issuecomment -310426634 기반

3년 전 이 호가 열렸을 때 자신이 무엇을 하고 있었는지 기억하는 사람이 있습니까?

비번들러 솔루션은 확장자로 .js 를 사용하여 웹 분산 프로젝트를 작성하는 것입니다.

100% 작동합니다. 더 큰 문제는 웹과 Node.js를 대상으로 하는 모듈을 작성하려는 것이지만 이는 일반적으로 JS의 문제입니다.

수행해야 할 일이 있으면 --moduleResolution=web 추가되지만 여기에서는 이 문제의 범위가 아닙니다.

.js 확장자를 추가하려면 이 빌드 후 스크립트를 작성해야 했습니다.

fix-ts-imports

#!/usr/bin/env sh

# Fixes JavaScript module imports generated by TypeScript without extension.
# Converts
# import {} from './module'
# into
# import {} from './module.js'
#
# EXAMPLE
# ./fix-ts-imports

ProjectDir="$(cd "$(dirname "$0")/.." && pwd)"

fix() {(
        local pkg="$1"
        shift

        find "$pkg" -type f -iname '*.js' -not -ipath '*/node_modules/*' -print0 \
        | while read -r -d '' file; do
                sed -i '' -E 's|(import .+ from ['\''"]\.?\./.+[^.][^j][^s])(['\''"])|\1.js\2|g' "$file"
        done
)}

if test $# -eq 0; then
        set -- "$ProjectDir"
fi

for pkg; do
        fix "$pkg"
done

JavaScript에서 비슷한 스크립트가 있습니다.
https://github.com/yoursunny/NDNts/blob/743644226fe18d48e599181e87ad571a2708a773/mk/build-post.js

다음과 같이 호출됩니다.

tsc -b mk/tsconfig-solution.json -w --listEmittedFiles \
  | node mk/build-post.js

이러한 종류의 스크립트의 주요 단점은 소스 맵을 깨뜨리므로 디버깅의 효율성이 떨어진다는 것입니다.

소스에서 최신 도구와 .js 확장을 사용하면 모든 것이 노드와 브라우저에서 훌륭하게 작동합니다.

• 타이프스크립트
• es 모듈
• 롤업

개발자가 이전 워크플로의 익숙한 랜드마크에 집착하기 때문에 여기서 문제가 있는 사람들이 실제로 es-module과 노드 해결의 깨진 하이브리드에 갇혀 있다고 가정할 수 있습니다. 아마도 webpack이 탓일 것입니다...

— 아마도 webpack이 탓일 것입니다...

그래서 고양이가 가방에서 나왔습니다.

소스에서 최신 도구와 .js 확장을 사용하면 모든 것이 노드와 브라우저에서 훌륭하게 작동합니다.

_대부분의_ 모든 것이 훌륭하게 작동하며 소스 파일의 내보내기에 .js 확장자가 있어야 한다는 데 동의합니다. 내 경험상, .js 확장 지원을 완강히 거부하기 때문에 이것으로 잘 작동하지 않는 한 가지는 ts-node입니다. 예, 노드를 실행하기 전에 사전 변환 단계를 추가할 수 있으며 .js 가져오기가 작동하지만 .ts 코드를 실행하거나 노드와 브라우저에서 직접 테스트하려면, 당신은 현재 대부분 운이 좋지 않습니다. (명확히 하자면 이것은 TypeScript 버그가 아니라 ts-node 버그라고 생각합니다.)

@chase-moskal 감사합니다.

repo와 tsconfig 파일을 리팩토링했는데 이제
import {something} from './something.js'
던지지 않는다
typescript force overwrite error TS5055: Cannot write file because it would overwrite input file
더 이상 fix-ts-imports 해킹이 필요하지 않습니다.

250개 이상의 댓글에는 명확성이 거의 없습니다. 요약:

배경

브라우저 모듈

브라우저는 상대 URL을 포함하여 URL에 따라 EcmaScript 모듈을 확인합니다. ( 뭐야 )

Node.js 모듈

Node.js는 여러 대체 및 package.json 파일 구문 분석을 포함하는 훨씬 더 복잡한 알고리즘을 통해 모듈(EcmaScript 및 Node.js 관련 CommonJS 모두)을 해결합니다. ( Node.js ) 예를 들어 전체 경로가 필요한 --experimental-specifier-resolution=explicit 로 사용자 정의할 수 있습니다.

TypeScript 모듈

TypeScript에는 사용 가능한 여러 모듈 해상도 알고리즘과 이를 추가로 사용자 정의할 수 있는 다양한 옵션이 있습니다. ( TypeScript ) 의도는 사용자가 생성된 출력에 사용된 것과 동일한 모듈 지정자를 작성하고 baseUrl 및 pathMappings와 같은 옵션으로 tsc의 해상도를 조정하는 것입니다.

실제로 대부분의 사용자는 Node.js 환경 또는 호환되는 번들러를 대상으로 하는 node moduleResolution을 사용합니다. 이 요청은 번들러가 없는 브라우저를 대상으로 하는 사용자에 중점을 둡니다.

ts-node 모듈 해상도

분명히 ts-node는 확장이 있는 모듈 식별자를 지원하지 않습니다 . 이유는 불명확하지만 Node.js와 TypeScript가 모두 하기 때문에 ts-node는 표면적으로 이들의 병합입니다.

사리

사실 1: .js 확장자를 사용할 수 있습니다.

더 광범위한 호환성(즉, 브라우저)을 위해 지금 .js 확장자를 사용할 수 있습니다. ts-node(IMO 버그)를 제외하고 전체 경로(확장자 포함)를 지정하면 모든 것이 바로 작동합니다.

사실 2: "확장 프로그램 추가"만큼 간단하지 않습니다.

이 요청은 "모듈 식별자를 파일 경로로 변환"으로 더 잘 요약됩니다. 예를 들어 ./example 는 ./example/index.js 가 되고 'lodash' 는 '.node_modules/lodash/index.js' 가 됩니다.

앰비언트 모듈 선언과 같이 확인된 파일 경로조차 없는 경우가 있습니다.

declare module "lodash" {
}

아마도 모듈 재작성은 현재 프로젝트/컴파일의 TS 모듈로 제한됩니다.

어쨌든 우리는 이제 TS의 설계 매개변수 중 하나를 위반하고 있으며, 다른 모듈이 현재 모듈의 출력에 영향을 줍니다.

결론

웹에서 작동하는 모듈 식별자에 경로를 사용할 수 있습니다. (예: ./foo/index.js 대신 ./foo .)

(실제로 말해서, 어쨌든 번들러가 브라우저를 대상으로 하기를 원할 것입니다. 즉, npm 패키지가 사용되는 경우입니다.)

@pauldraper "사실 2"에 중요한 문제가 있습니다.

이 요청은 "모듈 식별자를 파일 경로로 변환"으로 더 잘 요약됩니다. 예를 들어 ./example은 ./example/index.js가 되고 'lodash'는 'node_modules/lodash/index.js'가 됩니다.

패키지가 다른 곳에 설치될 때 사용할 수 있는 경로가 아닐 수 있으므로 컴파일 시간에 패키지 외부의 지정자를 확인하고 싶지는 않습니다. 각각의 고유한 패키지 설치에서 노드 모듈 확인을 실행해야 합니다. 그렇지 않으면 import {} from './node_modules/lodash/index.js' 를 작성하고 게시하고 끝낼 수 있습니다.

@justinfagnani , 동의하지만 이는 모듈 식별자가 추상적이고 tsc 외부의 모듈 위치를 조작하고 있음을 보여줍니다. 그리고 그 tsc는 그러한 조작에 관여할 수/필요하지 않습니다.

이 요청은 "모듈 식별자를 파일 경로로 변환"으로 더 잘 요약됩니다. 예를 들어 ./example은 ./example/index.js가 되고 'lodash'는 '.node_modules/lodash/index.js'가 됩니다.
앰비언트 모듈 선언과 같이 확인된 파일 경로조차 없는 경우가 있습니다.

이 요청에 대한 내용이 아닙니다. 코드를 내보낼 때 확장자를 추가하는 것입니다. 추가 해킹 단계 없이 "module" 유형과 호환되는 모듈을 작성하고 싶습니다. lodash와 같은 외부 모듈은 CommonJ이므로 .js가 없어도 계속 작동합니다.

예시:

// ./src/moduleA.ts
export const test = 2;

// ./src/moduleB.ts
import {test} from './moduleA'



md5-ec0300a1c6d92a03c70699d0e52c0072



```js
// ./lib/moduleB.js
import {test} from './moduleA.js'

위의 typescript 외에도 package.json "exports" 및 "type"을 지원하지 않습니다. 내가 관리하는 프로젝트에서 진정한 ESM을 향한 길은 없습니다.

이 요청은 번들러가 없는 브라우저를 대상으로 하는 사용자에 중점을 둡니다.

그것은 잘못된 것입니다. 저는 브라우저용 TS/JS를 거의 작성하지 않고 주로 서버 측 코드로 작업하며 노드에서 ESM 로딩을 사용하고 모듈 로딩을 위한 번들러 및 추가 코드에 의존하지 않기를 원하기 때문에 이것도 필요합니다.

lodash와 같은 외부 모듈은 CommonJ이므로 .js가 없어도 계속 작동합니다.

그들이하지 않는 한.

방출될 때.

./moduleA.js 일 수 있습니다. 아니면 ./moduleA/index.js , 맞습니까? Node.js 모듈 확인은 여러 경로를 허용합니다.

그들이하지 않는 한.

이것이 작동하지 않을 때의 예를 제공할 수 있습니까? Node.js는 CommonJS에서 명명된 내보내기 가져오기를 지원했습니다.
https://nodejs.org/api/esm.html#esm_import_statements

./moduleA.js일 수 있습니다. 아니면 ./moduleA/index.js일 수도 있습니다. 맞죠? Node.js 모듈 확인은 여러 경로를 허용합니다.

ESM 모드가 아닙니다. index.js는 지금처럼 더 이상 지원되지 않습니다. ESM 로더는 package.json 메타데이터 "내보내기" 및 "유형"을 읽습니다.
https://nodejs.org/api/esm.html#esm_mandatory_file_extensions

typescript + node.js 기반 프로젝트의 경우 더 나은 기본 ESM 스토리가 필요합니다. 이것은 도구(typescript) 또는 node.js에서 발생할 수 있습니다. 문제는 무엇을 해야 하는지에 대한 합의가 부족하다는 것입니다.

오해의 소지가 있는 노드 PR에 대한 제거된 링크를 편집합니다.