컨텍스트에 관계없이 모든 UMD 전역에 대한 액세스를 허용하는 대신 UMD 모듈이 ///<reference types=<>> 구문을 통해 명시 적으로 "참조"(가져 오기되지 않음) 된 경우 UMD 전역에 대한 액세스 만 허용하는 것이 더 간단하지 않을까요? , 또는 tsconfig.json의 types 구성을 통해?

즉, 모듈 내에서 ///<reference types=<>> 를 사용하도록 허용하지 않는 이유는 무엇입니까?

/// <reference type="x" /> 가 x 가 _everywhere_ 전역에서 사용 가능하다는 것을 의미했다면, 어딘가에있는 일부 .d.ts 파일이 실제로 전역이 아닌 것을 잘못 참조하는 경우가 자주 발생합니다 ( DefinitelyTyped의 2.0 브랜치를 관리해 왔고 매우 일반적인 오류이기 때문에 이것을 말할 수 있습니다.)

반대로 _ 해당 파일에서만 사용할 수 있다면 참조 지시문을 모든 곳에 복사하여 붙여 넣어야합니다. 정말 짜증납니다. 이러한 지시문은 일반적으로 멱등 성이기 때문에 파일 특정 동작을 도입하는 것이 이상합니다.

내가 참조. 글쎄, 이것이 다른 사람에게 영향을 미치지 않는다면 아마도 현재 행동을 유지하는 것이 낫습니다. 모듈로 가져 오는쪽으로 완전히 전환해야합니다.

편집 : 이것이 나 외에 많은 사람들에게 영향을 미치는 것을 보게되어 기쁩니다.

현재 이론은 사람들에게 모듈을 사용하여 마이그레이션하도록 요청하는 것입니다. 다른 사람들이이 문제에 부딪히면 더 자세히 조사 할 수 있도록 정확히 어떤 라이브러리를 사용하고 있는지 의견을 남겨주세요.

나는 자체 타이핑과 함께 제공되지 않는 lodash를 사용하고 있습니다. 또한 런타임 환경에서 상대 경로 가져 오기 문을 사용하는 것이 가장 쉬운 상황이 있습니다. 따라서 로컬 상대 경로 및 폴더 상대 ( './foo'및 'N / bar')가있는 import 문 조합이 있습니다.

@types/lodash/index.d.ts 을 node_modules/lodash/ 수동으로 복사하면 유형 검사를 할 수 있습니다.

지금까지 내 해결 방법은 ///<amd-dependency path='../lodash' name="_"> ( import 문 없음)을 사용하는 것이 었습니다. 이 콤보를 사용하면 @ types / lodash 정의가 컴파일러에 의해 '전역 적으로'표시되고 내 보낸 JS에 올바른 상대 경로 ( ../lodash )가 있습니다.

이 문제에 충분히 가까운 시나리오 였으면 좋겠어요.

명확히 할 수 있습니까

또한 런타임 환경에서 상대 경로 가져 오기 문을 사용하는 것이 가장 쉬운 상황이 있습니다.

과

@types/lodash/index.d.ts 을 node_modules/lodash/ 수동으로 복사하면 유형 검사를 할 수 있습니다.

부디? 이 시나리오에 익숙하지 않은데 그 목적은 무엇이며 왜 도움이됩니까?

안녕하세요 여러분,

현재 @types/bluebird 선언 문제 에 대한 해결책을 찾는 중입니다 (읽는 데 시간을 소비하지 마십시오). .d.ts에 export as namespace Promise; 을 추가하여 문제를 해결할 수 있다는 것을 알았지 만이 github 문제에서 설명한 문제가 발생했습니다.

요컨대, 다음 작업을 원합니다.

1. git clone -b vanilla-es5-umd-restriction-problem https://github.com/d-ph/typescript-bluebird-as-global-promise.git
2. cd typescript-bluebird-as-global-promise
3. npm install
4. export = Bluebird; 줄 위에 export as namespace Promise; node_modules/@types/bluebird/index.d.ts 을 추가하여 export = Bluebird; 합니다.
5. npm run tsc

현재 결과 :
몇 가지 'Promise' refers to a UMD global, but the current file is a module. Consider adding an import instead. 오류.

예상 결과:
컴파일이 성공합니다.

이 문제는 개발자 코드와 타사 코드 (이 경우 RxJS) 모두에서 Promise 사용으로 인해 발생하기 때문에 특히 어렵습니다. 후자는 Promise 가 전역 (JS 표준에 의해 제공됨)이라고 가정하므로 import Promise from std; // (not that "std" is a thing) 사용으로 변경되지 않습니다.

UMD 모듈을 가져 오기 가능한 모듈과 전역으로 사용하는 방법을 정말 고맙게 생각합니다.

감사.

----------------------------- 업데이트

저는이 문제를 다르게 해결했습니다 (즉, Promise 및 PromiseConstructor 인터페이스 확대).

"globals": [] tsconfig 옵션은 모든 곳에서 볼 수 있도록하는 것보다 선호됩니다. UMD 선언이 표준이되면서 실수로 모듈을 가져 오는 것을 잊어 버릴 가능성이 높습니다. 현재 동작을 유지하는 것을 고려하십시오. 오류 여야합니다.

일화로 포인트 릴리스에서 글로벌 window.moment 변수가 제거되었을 때를 기억합니다. 우리는 그것을 모든 곳에서 신중하게 수입하고 있다고 생각했지만 약 5 곳을 잊었습니다.

물론 UMD 패키지는 런타임에 전역 범위에서 사용할 수 있지만 사용할 수있게되는시기는 다른 모듈이로드되는 순서에 따라 다릅니다.

이것에 +1. SystemJS와 함께 React를 사용하려고했는데 React가 잘 번들링되지 않았기 때문에 CDN에서 스크립트 태그로 직접로드하기 때문에 React / ReactDOM 객체를 전역 적으로 사용할 수 있습니다.

모범 사례로 코드를 모듈로 작성하고 있지만로드시 실행되는 하나의 런타임 스크립트로 번들 (롤업)됩니다. import from react / react-dom을 수행 한 다음 로더가 "진짜가 아닙니다. 이들은 전역입니다"(https : /에 제공된 예제 WebPack 구성과 유사)라고 구성하는 것은 고통스럽고 거짓말입니다. /www.typescriptlang.org/docs/handbook/react-&-webpack.html). 내 모듈에서 이러한 기능을 전역으로 사용하는 것이 훨씬 쉽고 정확할 것입니다. 내가 시도한 단계는 직관적 인 것처럼 보였습니다.

1. npm install --save-dev @types/react @types/react-dom
2. 내 tsconfig.json에서 : "jsx": "react", "types": ["react", "react-dom"]
3. 내 모듈 : export function MyComponent() { return <div>{"Hello, world"}</div>; }
4. 유사하게 : ReactDOM.render(...)

그러나 이로 인해 React refers to a UMD global, but the current file is a module. Consider adding an import instead 오류가 발생합니다.

이것이 효과가 있었다면 코드에서 모듈 인 척하고 그렇지 않은 로더 / 번 들러를 구성하는 것보다 훨씬 간단 할 것입니다. (또는 아래에 포함 된 파일을 추가하여 예상 한대로 수행했습니다. 이제 내 모듈은 React & ReactDOM을 오류없이 전역으로 사용할 수 있지만 다소 추악하거나 해커입니다. 더 간단한 방법이있을 수 있습니다. 놓쳤다) :

import * as ReactObj from "react";
import * as ReactDOMObj from "react-dom";

declare global {
    var React: typeof ReactObj;
    var ReactDOM: typeof ReactDOMObj;
}

또한 옵션 3과 전역 : [] 백업에 동의합니다. 이는 신규 및 기존 사용자에게 매우 직관적으로 보이며 사람들이 필요로하는 정확한 기능을 제공합니다.

나는 코드에 대한 전문가가 아니기 때문에 2가 더 나은지 아닌지는 말할 수 없지만 구성이 간단하다는 점을 감안할 때 직관적 일 것이라고 생각합니다.

이러한 작업을 구현하는 데 도움을 받고 싶다면 어디로 가야합니까?

이것은 정말로 깃발 뒤에 있어야합니다. 엄청난 리팩토링 위험입니다. 플래그가 기본적으로 true로 지정된 경우에도 마찬가지입니다. 원래 시나리오에서 계속 작동해야한다고 생각합니다. 그렇지 않으면 UMD 선언의 주요 이점을 잃고 있습니다.

React는 잘 묶이지 않습니다.

@billti 자세히

import from react / react-dom을 수행 한 다음 로더가 "진짜가 아닙니다. 이건 글로벌입니다"라고 구성하는 것은 고통스럽고 거짓말입니다.

내가 튜토리얼에서 쓴 유일한 이유는 externals 를 사용하면 번들 시간이 줄어들 기 때문입니다. 임포트하지 않고 전역 React 변수를 사용하면 나중에 모듈로 쉽게 전환 할 수 없지만 임포트는 주어진 로더 중 하나를 사용할 수있는 유연성을 제공합니다.

번들링을 최적화하는 방법과 관찰 된 크기에 대한 한 가지 예는이 문제 (https://github.com/rollup/rollup/issues/855)를 참조하세요. 내 설정에서 효과적으로 (롤업을 사용하여) React를 번들링하는 최소 크기 증가를 보았으므로 CDN에서 제공하고 싶습니다. 나에게는 다음과 같은 이점이 있습니다.

a) 내 사이트에 대한 더 적은 요청 (및 대역폭).
b) 빌드 체인에 번들링하는 데 걸리는 시간이 줄어 듭니다.
c) 변경 사항을 푸시 할 때마다 클라이언트에 다시 다운로드 할 코드가 적습니다 (내 코드 만 다시 다운로드되는 번들에 있고 React는 수정되지 않은 상태로 클라이언트 캐시에 남아 있으므로 304s를 얻음).

사이트를로드 할 때 Chrome 개발자 도구를 살펴보면 GZipped HTTP 연결에서 React 및 React-dom (최소화 된 버전)은 47kb의 네트워크 트래픽으로 사이트의 대부분의 이미지보다 적으므로 그렇지 않습니다. 정말 큰 이득 (예 : 50 % 감소)이 없다면 어쨌든 그 정도를 줄이는 것에 대해 걱정했습니다.

부록으로 : 또한이 옵션이 없으면 TypeScript 컴파일러 자체가 "이 모듈은 실제로 전역 적"이라고 말하는 구성이 없기 때문에 이러한 가져 오기를 제거하는 번 들러를 사용하도록 강요하고 있습니다. 런타임에 해결되지 않는 모듈에 대한 가져 오기 (또는 필요 또는 정의)를 내 보냅니다.

@billti SystemJS는이 시나리오를 완벽하게 지원합니다. 개발 중에 로컬로 설치된 패키지를 사용하는 것과 프로덕션에서 CDN을 사용하는 것 사이를 바꿀 수 있습니다. 또한 모든 가져 오기가 실제로 한 번 가져 와서 처음 필요할 때 창 개체에 연결되는 전역 변수에 대한 참조를 나타내도록 지정하는 메타 데이터를 완벽하게 지원합니다. 프로덕션에서는 CDN에서 올 수 있습니다. 나는 반응으로 이것을하지 않았지만 각도 1.x로했습니다.

감사합니다 @aluanhaddad . 흥미롭게도 ... 저는 실제로 저를이 장애물로 이끈 비슷한 작업을하려고했지만 알아낼 수 없었기 때문에 오늘 아침 SystemJS 저장소에 질문을했습니다. https://github.com/systemjs/systemjs/issues/1510 달성 방법에 답할 수 있다면 정말 도움이 될 것입니다 :-)

참고 : 내 다른 의견은 여전히 ​​TypeScript 자체에 의한 방출은 코드 실행을 위해 가져 오기를 전역으로 매핑하기 위해 SystemJS / WebPack / Rollup 등과 같은 것이 필요하기 때문에 사용할 수 없다는 것입니다.

작업 예제를 만들 수 있는지 살펴 보겠습니다. 꽤 오랫동안 해본 적이없고 당시에 가지고 있던 소스 코드에 액세스 할 수 없지만 100 % 확신합니다. 있을 수있다.

두 번째 요점은 바로 SystemJS가하는 일입니다. 가져 오기를 글로벌에 매핑하고 글로벌이 실제로 요청되고 이미로드되었음을 이해합니다. 출력은 확실히 사용할 수 있습니다.

참고 : SystemJS API를 사용하여 SystemJS에서이 작업을 수행하고 https://github.com/systemjs/systemjs/issues/1510에 솔루션을 추가했습니다. 감사.

두 번째 요점 : 예, 이것이 바로 로더가 할 수있는 일입니다. 내 요점은 가져온 모듈을 전역에 매핑 할 수 있지만 TypeScript는 할 수 없기 때문에 런타임에 코드를 유효하게 만들기 위해 로더를 사용해야합니다. 따라서 이것은 원래 문제의 catch-22입니다. 여기서 전역 (이 경우 React)을 모듈에서 사용할 수 있다고 선언 할 수 없습니다. 마치 모듈 인 것처럼 가져와야합니다 (아니요). .

내 다른 의견은 여전히 ​​TypeScript 자체에 의한 방출은 코드 실행을 위해 가져 오기를 전역에 매핑하기 위해 SystemJS / WebPack / Rollup 등과 같은 것이 필요하기 때문에 사용할 수 없다는 것입니다.

@billti 이해가 안 돼요. 모듈의 글로벌 버전을 사용하는 것이 유일한 옵션이지만 TypeScript가이를 허용하지 않는 시나리오는 무엇입니까? 라이브러리가 전역 및 모듈 모두 로 사용 가능한 시나리오 만 보았습니다.

@DanielRosenwasser 저는 React가 실제로로드되는 방식 때문에 전역 객체의 구성원에서와 같이 런타임에 전역이라는 것을 의미한다고 생각합니다.

@billti 훌륭 합니다.

두 번째 요점 : 무슨 뜻인지 알겠습니다.

내 느낌은 브라우저 시나리오에서 RequireJS와 같은 로더 또는 Webpack과 같은 패키저를 사용해야하기 때문에 브라우저가 모듈을 지원하지 않지만 아무런 차이가 없기 때문이라고 생각합니다. (나는 Chakra가 깃발 뒤에 사용할 수 있다고 들었습니다). 따라서 추가 도구 없이는 코드를 전혀 실행할 수 없습니다. define , require 또는 System.register 를 포함하는 출력이 내 보낸 _JavaScript_ 코드가 이식 가능하지 않을 가능성이 있다는 의미입니다. 그러나 나는 "모듈과 모듈이 아닌"구별의 중요성을 알고 있습니다.

이 해결 방법을 사용하여 "모듈"을 한 번 이상 참조 할 수 있습니다.

_shims.d.ts_

import __React from 'react';

declare global {
  const React: typeof __React;
}

그런 다음 가져 오지 않고 다른 곳에서 사용할 수 있습니다.
또한 React가 글로벌화되었으며 더 이상 가져올 필요가없는 이유이기도합니다.

다시 shims.d.ts, 몇 개의 게시물을 올리면 내가 지금 한 일임을 알게 될 것입니다 (위대한 마음은 비슷하게 생각합니다) ;-)

이제 여러 가지 방법 중 하나로 작동하도록 할 수 있습니다. 그게 요점이 아닙니다. 우리는 TypeScript를 채택하기 쉽게 만들고 사용자가 절망의 구덩이가 아닌 성공의 구덩이에 빠지도록 노력하고 있습니다. 이를 염두에두고 TypeScript를 사용하고 문제를 해결하려고 할 때 종종 두 가지 질문을합니다. a) 유효한 코드입니까, b) 고객이이를 시도하고 수행 할 것입니까?

대략 입력하는 데 걸리는 시간에 대략적으로 Babel에서 원하는 작업을 수행하는 (비 TypeScript) 버전을 사용했기 때문에 코드가 유효하다고 말하는 것이 타당하다고 생각합니다. React 문서의 설치 페이지에 CDN의 스크립트 태그 를 하는 방법이 나와

TypeScript가 코드 작성의 특정 유효한 패턴을 지원하지 않을 경우 즉시 명확하게 만들고 사람들을 올바르게 안내해야합니다 (오류 메시지 또는 간결한 문서에서 수행하기 어려운 작업입니다). 그러나 개인적으로 TypeScript가 패턴을 지원하지 않아야한다고 생각합니다. 패턴이 "모범 사례"또는 "표준"이라고 생각하지 않기 때문입니다. 코드가 유효하고 일부 JavaScript 개발자가 코드를 작성하려는 경우 TypeScript가이를 지원해야합니다. TypeScript가 작동하도록 코드를 변경하고 빌드 파이프 라인을 재구성해야할수록 (예 : 사소한 앱을 마이그레이션하는 데 권장 됨) 개발자는 더 적게 이동합니다.

솔루션에 관해서는 ... 여기에서 그냥 뱉어 내지 만 아마도 프로젝트 전체에서 사용할 수있는 API를 이미 효과적으로 정의하는 "lib"컴파일러 옵션은 라이브러리가 전역 적으로 추가 할 수 있도록 @types/name 형식 값을 사용할 수도 있습니다. (그리고 어쩌면 상대 경로를 지원할 수도 있습니다).

우리는 TypeScript를 채택하기 쉽게 만들고 사용자가 절망의 구덩이가 아닌 성공의 구덩이에 빠지도록 노력하고 있습니다.

나는 우리가 지금 성공의 구덩이에 사용자를지도하려고 생각합니다. 모듈이 조건부로 전역을 정의하는 경우 실수로 사용자가 존재하지 않는 것을 사용하도록 안내하는 것입니다. 그래서 몇 가지 다른 옵션이 있습니다.

1. 모듈에서 가져 오지 않은 경우에만 표시되는 보강 된 export as namespace foo 구성을 만듭니다.
2. 아무 것도하지 않고 계속해서 사람들에게 가져 오기를 사용하도록 권장합니다. 어쨌든 오류 메시지를 합리적으로 규정했기 때문에 제 생각에는 다소 괜찮습니다.
3. 사람들이 어디에서나 UMD를 사용할 수 있도록 허용하십시오. 솔직히이 아이디어에 대해서는 그렇게 크지 않습니다.

@billti

다시 shims.d.ts, 몇 개의 게시물을 올리면 내가 지금 한 일임을 알게 될 것입니다 (위대한 마음은 비슷하게 생각합니다) ;-)

미안 해요, 너무 좋았어요;)

TypeScript가 패턴을 지원해서는 안된다고 생각합니다. 패턴이 "모범 사례"또는 "표준"이라고 생각하지 않기 때문입니다.

나는 TypeScript가 여기에서 규범 적이라고 생각하지 않으며, 그것이 주장하는 것을 수행하고 있다고 생각합니다. 많은 라이브러리에는 자체적으로 전역으로로드 한 다음 ES 모듈 구문을 사용하는 데모 및 자습서가 있습니다. 이렇게해서 그들이 위대한 시민이라고 생각하지는 않지만 그것은 또 다른 논의입니다.

즉, 모듈이 주로 전역에 대해 _ 지각 된 _ 구문 설탕으로 사용되는 경우 구문 설탕이 전혀 아니기 때문에 실패가 가까워집니다. 실제 코드 격리, 스크립트 태그 오딩으로부터의 자유, 명시 적 종속성 선언, 글로벌 네임 스페이스 지옥으로부터의 탈출 및 기타 이점과 같은 이점을 위해 소비하는 구문 적 소금 (아마 세금?) 일 경우. 모듈의 구문은 인체 공학적이지 않고 기껏해야 장황하지만 가치가있는 것은 모듈의 의미입니다.

사람들이 적어도 .ts 파일에서 TypeScript를 사용한다면 강력한 정적 코드 분석의 이점을 얻고 싶어한다고 생각합니다. Babel은 React가 존재하지만 그것에 대한 지식이 없다고 가정하여이를 수행하지 않습니다. 이는 ES 모듈이 정적 분석을 수행 할 수 있도록 의도적으로 지정 되었더라도 사실입니다.

안녕하세요.

모듈에서 가져 오지 않은 경우에만 표시되는 네임 스페이스 foo 구성으로 증강 내보내기를 만듭니다.

이 문제를 해결하는 가장 좋은 방법 인 것 같습니다.

이로 인해 문제가 발생한 또 다른 경우는 다음과 같습니다.

현재 작업중인 프로젝트에서 로컬 포함 (대부분 역사적인 이유로)을 npm 모듈과 혼합합니다. 결국 모든 것이 Rollup 또는 Browserify를 사용하여 결합되므로 괜찮습니다.

코드베이스에 복사 한 emojione 프로젝트의 .js 파일을 사용합니다. 나중에 DefinitelyTyped에 유형 선언을 추가했습니다. https://github.com/DefinitelyTyped/DefinitelyTyped/pull/13293 이제 단순히 유형을로드 할 수 있고 모든 것이 작동 할 것이라고 생각했습니다. 그러나 TypeScript는 내가 전역에 액세스하도록 허용하지 않기 때문에 그렇지 않은 것 같습니다.

내가 npm 모듈로 이동하지 않는 이유는 npm 모듈이 여러 메가 바이트의 스프라이트와 PNG를 번들로 제공하기 때문입니다. 200KiB 스크립트 하나만 있으면됩니다. 유형 선언 포함.

AngularJS에서 해결 방법은 declare var angular: ng.IAngularStatic 입니다. 하지만 네임 스페이스에서는 작동하지 않습니다.

@dbrgn 다른 문제가 발생했습니다. 모듈이 실제로 전역이면 유형 정의가 올바르지 않습니다. 전역을 선언하지도 않고 UMD 스타일 선언도 아닙니다 (이것은 UMD 스타일 선언에 관한 것입니다). 실제로 순수한 ES 모듈 만 선언합니다.

모듈이 전역을 나타내는 경우 파일의 최상위 수준에서 내 보내지 마십시오. 그러면 모듈이됩니다.

AngularJS에서 해결 방법은 var angular : ng.IAngularStatic을 선언하는 것입니다. 하지만 네임 스페이스에서는 작동하지 않습니다.

네임 스페이스와 함께 작동합니다.

디자인 회의에서 논의한 결과는 항상 UMD를 허용하고 현재 제한을 적용하는 플래그를 추가하는 것을 고려하고 있다는 것입니다. 제한은 UMD 전역에서 유형에 액세스하는 작업에도 확장됩니다.

이것에 대해 더 많이 생각했지만, 나는 여전히 새로운 선언 종류를 만드는 것이 더 좋은 것이라고 생각합니다. 이 플래그는 선언 파일 작성자가 한 번만 작성하면되는 새 구문보다 검색 가능성이 낮습니다.

이것은 기존 코드와 도구에 절실히 필요합니다. 자바 스크립트가 빠르게 재생을 멈추고 모듈 시스템에서 패배 할 때까지 코드가있는 그대로 유연하게 작업 할 수 있어야합니다. 경고를 내보내지만 빌드를 실패하지 마십시오. 롤업과 타이프 스크립트로 레거시 코드를 멋지게 만드는 데 며칠을 낭비했습니다.

UGH.

자바를 비웃는 것을 좋아하는 사람들이 많지만 기본 자바 모듈은 적어도 작동합니다. 항아리 작동

14 개의 서로 다른 임시 모듈 표준에 맞출 필요가 없으며, 그날의 롤업 / 번들링 도구가 실제로 사용하는 형식으로 소스 파일에서 js 모듈을 시도하고 컴파일 할 필요가 없으며 모듈 형식도 생성합니다. Typescript 가져 오기 / 내보내기 문 및 타사 d.ts 파일과 잘 어울리므로 TSC는 실제로 "단지 가져 오기를 사용하면 전 세계가 될 것입니다."라고 징징 대는 대신 코드를 빌드하기로 결정합니다. 실행 시간 ".

shims.d.ts 해킹이 잘 작동합니다. 하지만 어.

Webpack https://github.com/Microsoft/TypeScript/issues/11108#issuecomment -285356313을 사용하는 사용자를위한 임시 솔루션

원하는 UMD 전역으로 externals 을 webpack.config.js 에 추가합니다.

    externals: {
        'angular': 'angular',
        'jquery': 'jquery'
        "react": "React",
        "react-dom": "ReactDOM"
    }

기존 코드베이스를보다 쉽게 ​​마이그레이션 할 수 있어야한다고 생각합니다.

jQuery가 전역으로 포함되는 requirejs로 구현 된 프로젝트가 있습니다. 전역으로 발견되는 경우에만 jQuery를 확장하는 일부 플러그인이 있기 때문입니다.

일부 모듈의 코드는 해당 플러그인에 따라 다르며 jQuery를 모듈로 가져온 경우 사용할 수 없습니다. 이 작업을 수행하려면 모듈로로드 된 jQuery와 함께 작동하도록 모든 플러그인을 수정하고 모듈로도로드해야합니다 (필요한 위치를 추측).

게다가 모듈 로더없이 자바 스크립트를 사용하는 페이지도 있습니다. 따라서 플러그인은 전역 및 모듈 모두에서 작동해야합니다.

jQuery 외에도 녹아웃과 같은 문제가있는 다른 스크립트가 있습니다. 이로 인해 프로젝트 마이그레이션이 매우 어려워졌습니다. 또는 현실적인 관점에서 실행 불가능합니다.

물론 이것이 최선의 패턴은 아니며 새 프로젝트에서 사용하지 않을 것입니다. 하지만 나만이 문제가있는 것 같지는 않아

types 에서 tsconfig.json types 를 사용하는 것이 이치에 맞습니까? 예를 들어 types 설정하지 않으면 현재 암시 적 동작을 얻고 types 설정하면 문자 그대로 "이것들은 전역 적입니다"라고 말하고 UMD 네임 스페이스를 전역 적으로 표시 할 수 있습니다. 그것이 오늘날 존재하는 행동의 종류입니다 (전역 적 힘 빼기). 이것은 새로운 globals 옵션을 도입하는 것과 반대됩니다.

좋은 생각이라고 생각합니다. 제 경우에는 UMD 라이브러리를 전역으로 사용하고 다른 스크립트를 모듈로 사용하는 스크립트가 있습니다. 각 경우를 처리하는 두 개의 다른 tsconfig.json으로이 문제를 해결할 수 있습니다. 정말 간단합니다.

@blakeembrey types 사용하는 것이 이치에 맞지만 , 이미 문제가 있기 때문에 과부하라는 개념에 너무 열중하지 않습니다. 예를 들어 <reference types="package" /> 구성에는 이미 "paths" 지원하지 않는다는 제한이 있습니다. "package" 는 @types 의 폴더 이름을 참조해야합니다.

이 대화를 따라가는 데 어려움을 겪고 있습니다. 이에 대한 업데이트 또는 계획된 해결책이 있습니까? lodash가 응용 프로그램에 필수적인 부분이거나 더 많은 타사 라이브러리가 창에 의존하는 대신 더 모듈화 된 구조로 변환되는 경우와 같은 시나리오에서 유용 할 수있는 것 같습니다.

이 문제를 해결하기위한 계획된 방법이 있거나 적어도 현재 사용 가능한 릴리스에서이 문제를 해결해야하는 방법을 문서화 할 계획이 있습니까?

안녕하세요 @mochawich 저는 React를 외부로 정의하고 declare global 구문을 사용하지 않을 때 다음과 같은 오류가 발생합니다.

TS2686: 'React' refers to a UMD global, but the current file is a module. Consider adding an import instead.

@cantux TypeScript는 Webpack 구성을 읽지 않습니다. React를 전 세계적으로 사용 가능하게 만들었다면 declare 할 수 있지만 모듈을 사용하지 않는 이유는 무엇입니까?

@aluanhaddad 주로 가져 오기 호출로 수행 한 작업과 혼동했기 때문입니다. 나는 몇 가지를 만졌다. 다음 진술이 맞습니까?

우리는 모듈을 가져올 때 약간의 요청 비용을 지불하고 있습니다. 이것은 우리가 사용하는 것을 메모리에서 사용할 수 있는지 확인합니다. 이전에 요청한 경우 모듈이 캐시에서로드되고 모듈이 존재하지 않으면 가져옵니다. 이 요청을 피하려면 무언가를 전역으로 정의하면 Typescript가 사용 가능하다고 맹목적으로 신뢰합니다 (스마트 번 들러 가져 오기 문을 사용하는 경우 대체 / 제거 할 수도 있음).

이것이 맞다면 간결성을 위해 주석을 제거 할 수 있습니다. 스레드는 그대로 거대합니다.

@codymullins 가 위에서 질문했듯이

내 현재 해결 방법은 이전 작업 표준을 따르기 위해 typedef 파일을 해킹하는 것이었지만 더 많은 typedef 파일이 손상되기 시작하면 실행 가능하지 않습니다.

내 시나리오는 다음과 같습니다.

• 단일 페이지 앱에서 여러 라이브러리 (lodash 포함)를

위에서 언급 한 shim 예제는 작동하지만 vscode가 오류로 강조 표시하지만 (아직도 제대로 완료하더라도!)

모듈에서 UMD 전역에 액세스 할 때 오류를주지 마십시오. 제가 작업하고있는 대규모 프로젝트는 AngularJS에서 수행되었으며 애플리케이션에 Typescript를 사용하고 있지만 물론 angular UMD 전역 및 @types/angular Angular 유형에 대해 알기 위해서는 Typescript가 필요합니다. 당신은 추가하는 것만 큼 쉽게 될 거라고 생각하는 것 "angular" 에 types 에서 tsconfig.json 하지만, 어떤 이유, 그것은하지 않고, TSC 나를 비명. 모든 NPM 패키지가 순수한 Typescript 였으면하는만큼 대부분은 일반 JS이며 오랫동안 유지 될 것입니다. UMD 전역이 존재한다고 d.ts 가져올 때 TSC가 종료 할 수없는 이유를 정말로 이해하지 못합니다. 이 상황은 흔한 일이 아닙니다. 제가 작업 해본 모든 Typescript 프로젝트는 내가 묶어서 타입 정의를 사용하여 참조해야하는 하나 이상의 JS 라이브러리를 사용합니다.

이것에 대한 업데이트가 있습니까?

내 사용 사례 : CDN을 많이 사용하는 기존의 대규모 코드베이스에서 작업하고 있습니다. 공통 유틸리티는 여러 페이지 (예 : clipboardjs, lodash)에서 스크립트 태그를 통해 가져옵니다. 해당 전역 변수는 페이지에서 사용할 수 있으므로 참조하고 싶습니다. 모듈을 사용하지 않으면 관련 소스 파일의 맨 위에 /// <reference type="$name" /> 를 사용하여 typescript 컴파일을 수행하는 것이 쉽습니다. 그러나 이것은 모듈을 만들려고 할 때 작동을 멈 춥니 다.

스레드에서 제안 된 두 가지 접근법이있는 것으로 보입니다.

1. /// <reference type="$name" /> 가져 오기 토큰을 현재 파일의 네임 스페이스로만 가져옵니다.

2. tsconfig.json 의 컴파일러 옵션 / 구성 변수 (예 : "globals" , "types" )

두 가지 접근 방식이 모두 좋다고 생각합니다. @RyanCavanaugh 의 옵션 1에 대한 비판에 동의하지만 :

반대로 해당 파일에서만 사용할 수있는 경우 참조 지시문을 모든 곳에서 복사하여 붙여 넣어야하는데, 이는 정말 성가신 일입니다.

현재 동작으로 인해 UMD 전역과 함께 모듈을 전혀 사용할 수 없다는 것이 훨씬 더 성가신 일이라고 생각합니다. 일부 해결 방법은없는 것보다 낫습니다.

이 문제가 여전히 미결입니까? 그렇다면 현재 해결 방법은 무엇입니까?

@types 패키지를 설치하면 모듈로 가져 오지 않은 패키지를 전역으로 사용할 수 있습니다.

예를 들어, 프로젝트 루트에 npm install -D @types/underscore 이면 밑줄에서 아무것도 가져 오지 않는 모듈을 작성할 수 있지만 _ 전역을 사용할 수 있습니다 (아래 참조).

그게 당신이 추구하는 것입니까?

@billti 아마도 내가 오해하고 있지만 귀하의 예는 나를 위해 작동하지 않습니다.

재현에 필요한 최소한 :

js / foo.ts :

// <reference types="js-cookie">

import { Bar } from "./bar";

const Foo = {
    set: function() {
        Cookies.set("foo", "bar");
    },
    get: function() {
        console.log(Cookies.get("foo"));
    }
};

window.onload = function() {
    console.log(Cookies);
}

js / bar.ts

const Bar = {
    x: 3
};

export { Bar };

package.json :

{
  "name": "foo",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "private": true,
  "devDependencies": {
    "@types/js-cookie": "^2.1.0",
    "typescript": "^2.7.1"
  },
  "dependencies": {
    "http-server": "^0.11.1"
  }
}

tsconfig.json

{
    "compilerOptions": {
        "module": "system"
    },
    "files": [
        "js/foo.ts"
    ]
}

오류 메시지 :

js / foo.ts (7,3) : 오류 TS2686 : '쿠키'는 UMD 전역을 참조하지만 현재 파일은 모듈입니다. 대신 가져 오기를 추가하는 것이 좋습니다.
js / foo.ts (10,15) : 오류 TS2686 : '쿠키'는 UMD 전역을 참조하지만 현재 파일은 모듈입니다. 대신 가져 오기를 추가하는 것이 좋습니다.
js / foo.ts (15,14) : 오류 TS2686 : '쿠키'는 UMD 전역을 참조하지만 현재 파일은 모듈입니다. 대신 가져 오기를 추가하는 것이 좋습니다.

가져 오는 동작은 가져온 모듈이 "적절한"UMD 모듈로 작성되었는지 ( "쿠키"를 사용한 동작) 또는 "동시에 두 가지 방식으로 작동"모듈 (lodash 작성 방법)으로 작성되었는지 여부에 따라 다릅니다. .

개체가 런타임에 작동하는 방식을 설명하는 .d.ts 파일을 올바르게 작성하는 사람들의 불일치와 개발자를위한 경험의 불투명성 때문에 "UMD 전역 제한 제거"방향으로 상당히 기울이고 있습니다. --noStrictUMD 옵트 아웃으로 --strict 아래에 둘 수 있습니다.

내가 만난 다른 것은 Monaco의 맞춤형 AMD 로더를 다루는 것이 었습니다. 그들은 AMD 동작의 일부 하위 집합 (엄청난 아이 롤 삽입)을 지원하지만 글로벌 '필수'를 밟아서 적절한 UMD 모듈을 사용하기가 정말 어렵습니다. 해당 모듈은 '요구'글로벌을보고 제대로로드하지 못하는 경향이 있기 때문입니다. 모나코 모듈 로더. 결국 Monaco 로더의 스크립트 태그 위에 UMD JS 라이브러리를 넣은 다음 TS는 모듈 (Monaco API를 가져와야 함)에서 전역에 액세스하기 때문에 불평합니다.

안녕하세요.

내가 만난 다른 것은 Monaco의 맞춤형 AMD 로더를 다루는 것이 었습니다. 그들은 AMD 동작의 일부 하위 집합 (엄청난 아이 롤 삽입)을 지원하지만 글로벌 '요구'를 밟아서 적절한 UMD 모듈을 사용하는 것이 정말 어렵습니다. 모나코 모듈 로더.

😁

그들이 그것을 고칠 가능성이 있습니까?

저는 최근 모듈의 복잡성 비용에 대해 많은 생각을했습니다. 상호 의존적이며 부분적으로 호환되는 로더, 번 들러, 트랜스 파일러, 패키지 관리자 및 프레임 워크가 너무나도 많기 때문에 인증 복잡성이 그다지 중요하지 않습니다. (나는 당신이 어떤 알림도 필요하지 않을 것이라고 확신합니다 🙉).

개발자로서 우리는 5-6 년 전보다 훨씬 더 복잡한 툴체인을 받아들였으며 복잡성의 주요 원인은 모듈이었습니다.

포기하고 이러한 UMD 패키지를 전역으로로드하기 시작하면 모든 것이 무엇을위한 것일까 요?

하지만 ... 사람들은 그렇게하고 있습니다. 이것은 끔찍합니다!

내 말은,이 Stack Overflow Answer 는 61 👍을 가지고 있으며 지난 반년 동안 패키지의 99 %에 대해 모든 잘못된 것을 제안했습니다. (저자는 오늘 아침 제공된 피드백으로 인해 UMD 종속성에 대한 _option_ 모듈을 언급하도록 친절하게 업데이트했습니다.)

이 모든 것이 정맥에 들어가서 글로벌로 돌아갈 수는 없습니다!

하지만 ... 사람들은 그렇게하고 있습니다. 이것은 끔찍합니다!

문제는 JS 모듈의 구상과 구현이 몹시 형편 없기 때문에 전역을 사용하는 것이 훨씬 낫고 더 쉽다는 것입니다. 모듈이 처음부터 적절하게 설계되고 구현 되었다면 ...

다양한 로더 및 일부 로더와의 다양한 호환성 수준을 가진 모듈로 종속성을로드하는 것이 너무 번거롭기 때문에 모듈과 UMD 전역을 혼합하여 일치시키고 대신 직접 종속성 번들링을 지원하지 않고 달릴 분.

이 "기능"은 실제로 UMD 모듈을 사용하더라도 공식 UMD 모듈 지원을 사용하지 않음을 의미합니다. .d.ts 파일에서 전역으로 내보내고 모든 것을 다시 내보내는 해당 이름의 자체 모듈을 수동으로 갖게됩니다.

이것에 대한 업데이트가 있습니까? 옵션 2가 작동하기를 바랍니다.

일부 구문 또는 구성에서 "이 UMD 전역은 실제로 전역에서 사용할 수 있습니다."라고 표시하도록 허용합니다.

또한 구식 스타일의 js 라이브러리가 너무 많다는 것도 도움이되지 않습니다.
그리고 그것들을 모두 다시 쓰는 것은 의문의 여지가 없습니다. 단단한 운동
롤업이 모두 올바르게 처리하도록 구성하면 내 시간을 낭비합니다.

사람들은 "엔터프라이즈 자바"를 비웃지 만 평범한 자바는 실행 가능한
1.0에서 모듈 시스템. 완벽하지는 않았지만 완전한 엉망은 아니 었습니다.

"UMD 스타일 전역 허용"은 확실히 옵션이어야합니다.

2018 년 4 월 2 일 월요일 오전 1:40 Kagami Sascha Rosylight <
[email protected]> 작성 :

나는 해결해야했다 :

/ * 모듈 : es2015 * /
// js-yaml은 UMD를 지원하지만 ES2015 모듈은 지원하지 않습니다! import * as _jsyaml from "js-yaml"; declare var jsyaml : typeof _jsyaml; jsyaml.safeLoad ( "");

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/10178#issuecomment-377885832 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AA50ljAD33sr09EGFVAsURbu1x75X-lOks5tkeQCgaJpZM4Jd8jX
.

>

다니엘 조이스

온유 한자는 지구를 상속받을 것입니다. 용감한자는 별들 사이에있을 것이기 때문입니다.

Angular 프로젝트에서 three.js를 사용하고 있습니다. 나는 그것을 수입한다

import * as THREE from "three";

import {Vector3} from "three"; 도 예상대로 작동합니다.

three 및 @types/three npm 패키지가 설치되어 있으면 모든 것이 정상적으로 작동합니다. 내부적으로 three/build/three.module.js 사용하고 있다고 생각합니다. @types/three/index.d.ts 파일은 export as namespace THREE 표기법을 사용하는데, 제가 완전히 익숙하지는 않지만 작동합니다.

이 특별한 경우에 문제는 three.js 시스템에 OrbitControls.js 라는 또 다른 관련 파일이 있다는 것입니다 (기본적으로 손가락이나 마우스로 3D 이미지를 회전 할 수 있음). 문제는이 함수가 반 공식적으로 three.js 배포의 일부이지만 examples 트리에있는 평범한 이전 JS 파일이며 THREE 속성에 직접 배치된다는 것입니다. 의 다른 API를 직접 사용하고 window.THREE 에서 찾을 것으로 예상되는 다른 API를 직접 사용합니다. 따라서 파일이 "필요"하더라도

require("three/examples/js/controls/OrbitControls.js");

window.THREE 를 찾을 수없고 자신이 사용하는 THREE 시스템의 다른 부분에 액세스 할 수 없습니다. 내가 직접 각도 사용하여 전체 라이브러리를 포함 할 수 scripts 재산 angular.json (구식 거의 비슷 <script> 하지만 내가 잘못 난 아니에요 경우, 태그) 라이브러리를 두 번로드했습니다.

이를 방지하기 위해 import * as THREE from "three"; 문을 제거했습니다. foo: THREE.Vector3 와 같은 유형은 여전히 ​​확인할 수 있지만 new THREE.Vector3() 같은 참조는 악명 높은

'THREE'는 UMD 전역을 참조하지만 현재 파일은 모듈입니다. 대신 가져 오기를 추가하는 것이 좋습니다. [2686]

이 시점에서 저는 OrbitControls.js 파일과 ES6-ify 및 / 또는 TS-ify 파일을 가져와야 할 것이라고 생각하고 있습니다. 'orbit-controls-es6' 와 같은 형식이므로 다른 사람의 손에 내 삶을 맡기는 것을 싫어하더라도 내 삶을 단순화하고 사용하는 것이 좋습니다.

반 관련되지 않은 메모에서 한 가지 이상한 점은 @types/three 코드 자체가 three 모듈 자체에 있지 않더라도 OrbitControls 유형을 정의한다는 것입니다. 그러나 OrbitControls 라는 클래스를 정의하는 모든 유형을 어떤 것과도 연관시키는 방법을 알 수 없습니다. 위에서 언급 한 orbit-controls-es6 의 기본 내보내기를 선언하고 싶습니다. 이 유형이지만 그렇게하는 방법을 알 수 없습니다.

내가 마침내 생각해 낸 해결책은 다음과 같습니다.

import * as THREE from "three";
Object.defineProperty(window, "THREE", {get() { return THREE; }});
require("three/examples/js/controls/OrbitControls.js");

이유는 약간 혼란 스럽지만 작동합니다. 필수 파일에는 다음과 같은 행이 있습니다.

THREE.OrbitControls = funtion() { };

작동하지 않아야하는 import * as THREE from "three"; 문으로 인해 결과적으로 3 개의 "네임 스페이스"에 할당되는 것처럼 보입니다.

@RyanCavanaugh 가 # 26223의 피드백을 여기에 복사 해달라고 요청했습니다.

나는 사람들이 의존하는 몇 가지 확실히 형식화 된 라이브러리가있는 다소 큰 TypeScript 코드베이스 (Google의 내부 모노 레포)를 유지하고 있습니다. 원래 사용자는 .d.ts 가 외부 모듈로 바뀌기 전에 angular 와 같은 라이브러리에 대해 전역 유형에 의존했습니다. 그런 다음 모듈과 명시 적 가져 오기를 사용하기 위해 코드베이스를 마이그레이션했습니다. 실제로 export as namespace d UMD 전역은 유형 및 값 참조 모두에 대해 기호를 사용하기 위해 항상 명시적인 가져 오기가 필요하다고 예상했으며 마이그레이션 할 때 다시 알아 차리지 못했습니다 (웃음).

가져 오지 않은 코드 사용을 허용하는 것은 일반적으로 문제가됩니다.

• 이는 코드가 전역 "백그라운드"유형 정의에 의존하여 코드를 읽기 어렵게 만드는 것을 의미합니다 (특히 리포지토리 브라우저 또는 기호로 이동하지 않는 코드 검토에서).

• 코드 종속성을 모호하게합니다.

• 그것은 우리가 bazel에서 구현하는 "엄격한 deps"라고하는 "모든 임포트에 대해 명시적인 빌드 레벨 의존성을 가져야합니다"제약을 우회합니다.

  대규모 코드베이스에서는 코드에 명시적인 종속성이 있어야합니다. 그렇지 않으면 저장소를 관리 할 수 ​​없게됩니다. 이제 A -> B -> C 및 전역 유형을 추적하는 종속성이있는 경우 B 에 C 에 대한 종속성이 있기 때문에 B A 코드를 컴파일하기가 쉽습니다. 나중에 B 가 종속성을 제거하면 A 가 중단됩니다. 이는 변경 사항이 저장소에 예기치 않은 파급 효과를 가져와 코드 격리를 위반 함을 의미합니다.

• 이로 인해 코드가 값에 대해 하나의 접두사가있는 모듈을 일관성없이 가져오고 다른 접두사와 함께 해당 유형을 사용합니다 (특히 AngularJS, ng 대 angular의 경우).

공급 업체의 DefinitelyTyped 사본에서 export as namespace 문을 제거하여이 문제를 해결할 수 있지만, 적어도 우리에게는이 기능이 코드 유지 관리 및 엔지니어링 목표에 반하는 것입니다. 나는 문제가 구글과 같은 단일 저장소 상황에서 더 두드러진다 고 생각하지만 일반적으로 더 작은 코드베이스에도 적용된다.

귀하가 게시 한 사항은 우리 상황에 절대적으로 중요하지 않습니다. 우리는 AMD 모듈로 우리 자신의 코드를 구현하고 우리가 통제 할 수없는 상황으로 인해 UMD 모듈에 의존성을 제공해야합니다 (하지만 JS 모듈은 개념과 구현 모두에서 끔찍한 결함이있는 것으로 요약하겠습니다). 이 기능을 통해 우리는 삶을 상당히 단순화 할 수 있습니다.

TS3를 사용하면이를 방지 할 수있는 방법을 알아낼 수 있었지만 그렇게하더라도 필요한 모든 변경 사항을 완료하기까지는 적어도 2 년이 걸릴 것이므로 여전히 매우 유용한 기능이 될 것입니다.

열린 질문 : " 모든 UMD 모듈에 대한 액세스 허용"에 대한 하나의 전역 플래그로 충분합니까, 아니면 사람들이 실제로 오류에 대한 모듈 별 제어가 필요합니까?

"단지 하나의 깃발"에 ❤️ 투표
"모듈 별 제어 필요"에 🎉 투표

또한 tsconfig.json 의 "types" 옵션에 명시적인 목록이 있어도 모듈에서 UMD 사용을 허용하지 않는지 고려하고있었습니다. 유형이 의도적으로 존재 함을 의미합니다. (분명히 가져 오는 것을 잊은 오류를 배제하지는 않습니다).

또는 유사하게 /// <reference types="..." /> 구조를 사용하면 사용되는 모듈 (즉, 언급 된 '모듈 별 컨트롤')에서 해당 패키지의 UMD 사용을 허용해야합니다.

@RyanCavanaugh # 26233에도 플래그를 지정할 예정입니까?

26233은 의도 한대로 완전히 작동하는 것으로 간주됩니다. 모듈에서 UMD 전역의 유형 측면에 액세스하는 것은 합법적으로 무해합니다.

나는 그것이 "합법적으로 무해한 지"확실하지 않다. @types/jquery 를 예로 사용합니다. $ 및 jQuery 는 JQueryStatic 인터페이스에 매핑되고 상수로 내 보냅니다. 결과적으로 모든 모듈은 가져 오기없이 $ 및 jQuery 액세스 할 수 있습니다. 나는 그것을 비활성화 할 수 있기를 바랍니다.

@RyanCavanaugh 예, TS 방출이 영향을받지 않는다는 점에서 무해합니다. 각 라이브러리가 액세스 할 수있는 @types 대한 세밀한 제어를 원한다면 문제가됩니다. 최소한 모듈 범위 유형처럼 보이는 것을 전역 유형으로 바꾸는 것입니다. 방출이 영향을받지 않더라도 액세스 확대도 문제가 될 수 있습니다.

실제로 jQuery의 경우 emit가 영향을받습니다. $() 는 가져 오기없이 모듈에서 내 보냅니다.

모든 모듈에서 UMD 전역에 대한 액세스를 허용하는 새 플래그에 대한 PR 수락.

구현 측면에서는 매우 간단하지만 이름을 지정해야합니다. 우리는 제안 검토 회의에서 수십 명의 끔찍한 이름을 걷어차 고 모두 싫어 했으므로 맛있는 것을 생각해내는 것은 모두에게 달려 있습니다. 중단하십시오.

우리는 제안 검토 회의에서 12 명의 끔찍한 이름을 걷어차 고 모두 싫어했습니다.

그들은 무엇입니까?

그래서 맛있는 것을 생각해내는 것은 여러분의 몫입니다.

umdUseGlobal 또는 다른 것.

UMD 전역은 일반적으로 export as namespace 이므로 UMD 전역 플래그의 이름으로 importAllNamespaces 를 제안합니다.

@RyanCavanaugh 팀이 유형 문제에 대해 논의 했습니까?

@FranklinWhale 예.

@saschanaz 이미이 질문을했지만 저도 궁금합니다 ... @RyanCavanaugh 어떤 끔찍한 이름이 논의되었는지 기억하십니까?

체인이 이렇게 된 것 같아요

• allowUmdGlobalAccessFromModules -가장 정확하지만 너무 길다
• assumeGlobalUmd -어
• allowModuleUmdGlobals - "전역"??
• umdAlwaysGlobal -🤢
• allowUmdGlobals -하지만 이미 할 수 있습니까?
• allowUmdGlobalAccess -모듈 부분을 건너 뛰지 만 아무도 신경 쓰지 않습니까?

강제하면 마지막 하나를 선택합니다

감사합니다!

나는 allowUmdGlobalAccessFromModules 를 가장 좋아하는데, 길이는 길지만 그 정밀도는 기억하기 쉽기 때문입니다. "모듈에서 UMD 전역에 액세스 할 수있는 옵션은 무엇입니까? 아, 물론 allowUmdGlobalAccessFromModules 입니다!"

접두사 "allow"를 사용하면 다른 옵션의 명명 규칙과 일치합니다.

게다가 ... 약간의 다른 옵션이 있습니다 :)

allowUmdGlobalAccessFromModules : 31 자

allowSyntheticDefaultImports : 28 자
strictPropertyInitialization : 28 자
suppressExcessPropertyErrors : 28 자
suppressImplicitAnyIndexErrors : 30 자
forceConsistentCasingInFileNames : 32 자

현재 해결 방법은 무엇입니까? 지난 한 시간 동안 인터넷 검색을했는데 실행 가능한 솔루션을 찾을 수 없습니다.
차라리 '아무'로 캐스팅하거나 작동하는 Typescript 버전으로 다운 그레이드하지 않고 다른 옵션을 찾을 수 없습니다.
이 문제를 해결하는 컴파일러 플래그가있는 실험적 빌드가 어딘가에 있습니까?
(그런데 'allowUmdGlobalAccessFromModules'는 훌륭한 이름입니다. 하루에 50 번 입력하는 것과는 다릅니다. :-))

우리는 최상위 HTML 파일에 정적으로 포함 된 lodash와 함께 tsc 3.2.2를 사용하고 있습니다. require.js로; 최신 DefinitelyTyped에서 얻은 d.ts 컴파일에 실패한 예제 코드 :

/// <reference path="..." />

class Example<T extends IThingWithTitle<T>> {

    public test = (arg : T[]) : void => {
        _.sortBy(arg, (el : T) => { return el.title; }); // TS2686: '_' refers to a UMD global, but the current file is a module. Consider adding an import instead.
    };

}

export = Example;

(프로젝트를 거꾸로 뒤집어 야한다고 말하지 마세요. 우리가 어떤면에서 뒤쳐져 있다는 것을 압니다)

업데이트 : ((window) ._) / * FIXME https://github.com/Microsoft/TypeScript/issues/10178 * /. sortBy (...) 작동하지만 주님, 추악합니다 :-P

@Gilead ,이 댓글의 솔루션은 현재 잘 작동합니다. https://github.com/Microsoft/TypeScript/issues/10178#issuecomment -263030856

이것에 진전이 있습니까? 이 문제가 발생했기 때문에 언급 된 해결 방법이 작동하지 않는 경우가 있습니다 ( [email protected] ).

먼저 이것을 시도했습니다.

import 'firebase';

declare global {
  const firebase;
}

이는 전역 firebase 에 any 유형을 암시 적으로 제공 한 다음 네임 스페이스 (동일한 이름)를 여기에 적용합니다. 먼저 firebase 모든 최상위 키에 대한 적절한 툴팁 / 지능을 보여주기 때문에 작동하는 것처럼 보였습니다.

그러나 실제로 작동하지 않습니다 (그런 다음 any 유형으로 사용하도록 전환하기 때문에 버그 일 수 있습니까?) :

그래서 나는 성공하지 않고 여기에 언급 된 해결 방법을 시도했습니다 (다른 사람들에게도 작동합니다).

import _firebase from 'firebase'; // same with = require('firebase') 

declare global {
  const firebase: typeof _firebase;
}

=> 'firebase'는 자체 유형 주석에서 직접 또는 간접적으로 참조됩니다.
(네임 스페이스가 별칭이 있더라도?)

나는 또한 시도했다

import * as _firebase from 'firebase';

declare global {
  const firebase: typeof _firebase;
}

=> 가져 오기 별칭 '_firebase'의 순환 정의.
( 정의 에 export = firebase; export as namespace firebase; 때문 일까요?)

그리고 마지막으로 import 'firebase' 수행하면 다시

'firebase'는 UMD 전역을 참조하지만 현재 파일은 모듈입니다. [2686]

누구든지 이것에 대한 해결책이 있다면 매우 감사 할 것입니다. 그렇지 않으면 지금까지 언급 된이 문제를 해결하기위한 제안 중 하나가 정말 괜찮은 것 같습니다 (플래그, 트리플 슬래시 참조, tsconfig의 types , global 또는 external 개체 포함) tsconfig에서).

Re @aluanhaddad 님 의 코멘트

이 모든 것이 정맥에 들어가서 글로벌로 돌아갈 수는 없습니다!

나는 전역으로 돌아 가려는 것이 아니라, 몇 가지 이점을 제공하기 때문에 내 앱 번들과 별도로 몇 가지 무거운 종속성을로드하면서 다른 모든 작업에 모듈을 사용하려고합니다. 종속성이 제대로 캐시 될 수 있습니다. 내 앱 번들만큼 자주 업데이트되지 않기 때문입니다. 내 번들 크기가 폭발하지 않습니다 (때로는 코드 분할로 인해 번 들러에 동일한 종속성이 여러 번 포함됨). 이는 내 앱 사용자의 다운로드가 적다는 것을 의미합니다. 개발 중에 내 번들을 재 구축하는 것이 훨씬 빠릅니다.

이것은 추가하기 매우 쉬운 기능입니다. 커뮤니티 회원이 그것을 받아들이는 것이 좋을 것입니다.

@RyanCavanaugh 나는 그것을 들여다과 종류 생각의 난에 옵션을 추가 할 필요가 밖으로 compiler/types.ts 하고있는 UMD 글로벌 체크 수정 compiler/checker.ts 하고, 나는에 추가 할 필요가 있다고 생각 compiler/commandLineParser.ts 뿐만 아니라 ...하지만 소스에 전혀 익숙하지 않기 때문에 완료하는 데 꽤 시간이 걸릴 것이라고 생각합니다 (i18n을 깨지 않고 CLI 플래그에 대한 설명을 추가하는 방법처럼) . 지금은 이미 출처를 알고있는 다른 사람이 그것을 받아 들일 때까지 기다릴 것입니다.

@simonhaenisch 비 모듈 선언 파일에서 선언 할 수 있으며 순환 참조를 피하기 위해 다른 UMD 모듈 선언에서 다시 내보낼 수 있습니다. 원래 firebase 는 네임 스페이스로 선언되어 있습니다. 운이 좋게도 오류를 일으키지 않고 선언을 확장합니다.

// umd.d.ts
import firebase = require("firebase");
export import firebase = firebase;
export as namespace UMD;

// global.d.ts
declare const firebase: typeof UMD.firebase;

안타깝게도 선언 한 것은 네임 스페이스가 아니라 값이므로 let x: firebase.SomeInterface 와 같은 작업을 할 수 없습니다. 네임 스페이스의 별칭을 지정하는 유일한 방법은 가져 오기를 선언하는 것입니다.하지만 declare import firebase = UMD.firebase; 는 할 수 없습니다.

이전 주석과 유사하게 hls.js (UMD) 및 참조 유형을 지연로드합니다.

hls.d.ts :

import * as Hls from 'hls.js';
declare global {
    const Hls: typeof Hls;
}

지연로드 된 UMD 모듈을 사용하는 .ts 파일에서 :

/// <reference path="hls.d.ts" />
// now use it
if(Hls.isSupported()){
 ...
} 

Typescript> = 3.0.1 및 3.4.1에서 테스트되었습니다.

근거는 동적 모듈 가져 오기에 대한 불완전한 브라우저 지원입니다.

@MatthiasHild /// <reference path="hls.d.ts" /> 주석없이 할 수 있습니까?

편집, 예, 선언이 포함 된 .d.ts 파일 내에있는 한이 SO 질문을 기반으로 다른 .ts 파일과 동일한 이름을 갖지 않는 한 그리고 내가 물은 이유).