Typescript: 강제 수입

쓰기를 통해 강제로 방출 할 수 있어야합니다.

var myExternalModule = require("./myExternalModule");

그러나 "./myExternalModule"이 잘못된 경로이면 불평하지 않습니다.

올바른 접근 방식은 부작용이없는 더미 참조를 도입하는 것입니다.

import myExternalModule = require("./myExternalModule"); 
myExternalModule;

이것은 해킹이지만 다소 좁은 사용 사례에 대해 새로운 구문이 도입 될 가능성은 거의 없습니다. 디자인 목표를 확인하십시오.

TypeScript가 var myExternalModule = require("./myExternalModule"); 의 경로를 확인하면 사용자가 해킹에 의존하지 않고도 강제로 emit _ 및 _ 컴파일 타임 확인을받을 수 있습니다.

var 접근 방식은 모듈에서 유형을 가져 오지 않습니다.

또한 필요한 경우 amd-dependency 속성을 사용할 수 있습니다.

사용하지 않는 물건을 수입하는 목적은 무엇입니까?

예를 들어 각도 앱에서 다른 파일에 몇 가지 지시문이 있습니다. 이러한 지시문을 가져와야합니다. 그렇지 않으면 html 마크 업이 작동하지 않습니다. 그래도 JavaScript에서는 사용하지 않습니다.
일반적으로 각도에서 대부분의 모듈은 분리되고 서로 종속성이 없지만 전체 앱이 작동하려면 가져와야합니다.

: +1 :
헷갈리네요.
TypeScript 컴파일러가 그것을 제거하는 이유는 무엇입니까?
외부 모듈은 인스턴스화되지 않은 모듈이 아닙니다.
필요는 부작용이 있습니다.
import 절은 AMD 및 CommonJS의 요구 사항과 호환되는 것으로 보입니다. 하지만 그렇지 않습니다.

이 문제는 실제로 아무것도 내 보내지 않고 대신 es5-shim , es6-shim 등과 같은 전역 개체에 대한 shim 기능을 사용하는 require ()-ing 모듈도 성가 시게합니다.

헷갈리네요.
TypeScript 컴파일러가 그것을 제거하는 이유는 무엇입니까?

때로는 모듈에서 유형 정보 만 가져오고 싶기 때문에 최적화입니다.

import foo = require('foo');

function bar(paramOne: foo.ParamOne, paramTwo: foo.ParamTwo){}

단지 최적화가 아닙니다. 가져온 모듈을 유형에만 사용하는 경우 (즉, 값 위치에서 사용되지 않음), 모듈이 런타임에 존재하지 않는 주변 유형 전용 모듈 일 수 있으므로 이에 대한 필수 로직을 내보낼 수 없습니다. 모듈 가져 오기를 내 보내면 존재하지 않는 모듈을로드하려는 런타임 오류가 발생합니다.

이를 위해 amd-dependency 플래그를 사용할 수 있습니다.

/// <amd-dependency path="foo" />

import x = require('foo');

약간의 해킹처럼 보이는 <amd-dependency> 대신 <reference name="..."> IMO를 사용하는 것이 흥미 로웠을 것입니다.

@danquirk TypeScript 엔진이 import 문을 최적화하는 책임을 맡는 것은 임의적이고 위험한 일입니다. TypeScript가 아직 JavaScript에서 캡처하지 않는 패턴이 많이 있습니다. 한 가지 예는 this 이 # 229 유형을 가질 수 있다는 것을 해결하지 않는 방법입니다.

Import는 현재 코드가로드되기 전에 종속성을로드하는 데 사용되며 직접 참조 할 수 없습니다. 각도 종속성은 한 가지 예이며 jQuery 플러그인은 또 다른 예입니다. 기본 개체를 확장하고 직접 참조되지 않는 모든 라이브러리는 "기능"의 영향을받습니다. 로컬 정적 분석을 기반으로 임포트를 임의로 포함하지 않기로 결정함으로써 임포트 문을 작성한 개발자의 명시적인 의도에 대해 C 스타일 컴파일러 패턴을 부과하게됩니다. import 작성에 대한 기대는 종속성으로 포함되고 모듈의 로컬 범위에서 사용할 수 있다는 것입니다. 다른 모든 작업은 모듈 내부에 import 를 작성하기로 선택한 자연스러운 기대에 대한 부작용입니다.

이 경우 TypeScript 컴파일러는 더 적은 작업을 수행하고 더 많은 작업을 수행 할 수 있습니다.

TypeScript 차기 릴리스는 ES6 스타일 모듈을 지원합니다 (현재 변경 사항은 마스터에 있음). 따라서 원하는 모든 것이 종속성을 선언하는 것이라면 다음을 사용할 수 있습니다.

import "myLib";

컴파일러는이 가져 오기를 제거하지 않습니다.

기존의 일관되지 않은 행동이 해결 될까요, 아니면 사람들이 발견 할 수있는 재미있는 것으로 남을까요? import 가 파일을 종속성으로 추가하지 않는 경우 문서에 추가해야합니까? TypeScript AMD 모듈을 빌드 할 때 ///<reference... 이제 오류로 간주됩니까?

현재 import 작동 방식은 잘못된 설계입니다. 나쁜 디자인은 모호성을 만듭니다. 추가 동작이 명확하게 정의되지 않으면 부작용이지만 발견 될 가능성이 높습니다. 따라서이 포럼에서 OP, 나 자신 및 이와 관련된 기타 의견 및 버그가 있습니다.

Common 또는 Require 스타일 종속성 관리를 사용할 때 이미 존재하는 기존 사례가 있습니다. import 의 구현은 무시되었음을 보여줍니다.

문서와 관련하여 사양 섹션 11.2.5 및 섹션 11.2.6을 참조하십시오.

외부 가져 오기 선언은 생성 된 JavaScript에서 모듈 시스템 호스트에서 제공하는 'require'함수에 대한 호출로 초기화 된 변수로 표시됩니다. 가져온 모듈 또는 가져온 모듈을 참조하는 로컬 별칭 (섹션 10.3)이 가져 오는 모듈의 본문 어딘가에 PrimaryExpression으로 참조되는 경우에만 특정 가져온 모듈에 대해 변수 선언 및 'require'호출이 발생합니다. 가져온 모듈이 ModuleName 또는 TypeQueryExpression으로 만 참조되는 경우 아무것도 방출되지 않습니다 _.

/// 참조는 가져 오기와 동일하지 않습니다. /// 참조는 전역 범위에 추가 선언을 가져옵니다 (예 : dom API). 이러한 엔터티의 존재를 신뢰하는 것은 컴파일러에 대한 진술이며 생성 된 코드에 영향을주지 않습니다.

반면에 import는 require 문으로 내 보내야합니다. 유형 위치에서만 가져 오기를 사용하는 경우 의도가 명확하지 않으며 유형 (런타임에 존재하지 않는 디자인 타임 구성) 만 원하며이 경우 가져 오기를 제거하려는 경우 , 그렇지 않으면 존재하지 않는 유형 전용 모듈을 가져올 수 있습니다. 아니면 부작용도 원합니다. 후자의 경우 import "mod"; 구문이 의도를 선언하는 데 더 명확한 구문 인 것 같습니다.

@mhegazy 나는 새로운 문제를 열고 싶지 않지만 이것은 React 세계에서 약간의 문제입니다.
아래 코드를 살펴보면 js로 컴파일 할 때 React 참조가 코드에 표시되지 않으므로 제거되고 ReactRouter 따라 코드가 실패합니다. 수정은 ... 정말 바보가 코드 아래에 있습니다. 더 똑똑한 방법이 있습니까? 감사.

import * as React from "react"; var temp = React.DOM;
....

// mf("route.schedules", "") // this is to register a translation
anonymousRoutes.route("/schedules", {
  name: "schedules",
  subscriptions: function() {
    this.register("schedules", subscriptions.subscribe("schedules"));
  },
  action: () => {
    ReactLayout.render(ClearLayout, {content: <Book />});
  }
});

수정;)-EHM

import * as React from "react"; var temp = React.DOM;
...

ReactRouter가 의존하므로 코드가 실패합니다.

var "React"또는 가져 오기의 일부 부작용이 필요합니까?

가져 오기의 부작용이 필요합니다. var는 트랜스 파일 된 코드에서 가져 오기를 제거하지 않기 위해 추가되었습니다.

그래서 그냥 추가하지 않는 이유

import * as React from "react"; // get the types
import "react";  // just for side effect

출력에서 마지막 가져 오기 : import "react" 는 제거되지 않습니다.

불행히도이 다 우즈는 작동하지 않으며 여전히 다음과 같은 결과를 얻습니다.

ReferenceError: React is not defined
    at action [as _action] (schedule_router.jsx:15)
    at Route.callAction (kadira_flow-router.js?f961d732ed2b89a53d490af5979b899800aa1a5d:2306)
    at kadira_flow-router.js?f961d732ed2b89a53d490af5979b899800aa1a5d:2025
    at Object.Tracker.nonreactive (tracker.js:560)
    at kadira_flow-router.js?f961d732ed2b89a53d490af5979b899800aa1a5d:2016
    at Tracker.Computation._compute (tracker.js:294)
    at Tracker.Computation._recompute (tracker.js:313)
    at Object.Tracker._runFlush (tracker.js:452)
    at Object.Tracker.flush (tracker.js:412)
    at Router._invalidateTracker (kadira_flow-router.js?f961d732ed2b89a53d490af5979b899800aa1a5d:2065)

나는 여기에 필요한 모든 참조를 제공하기 위해 _callee_에 의존하는 Meteor의 "약한 종속성"이라고 생각합니다.

저는 최근 Angular 2의 타이프 스크립트를 배우기 시작했습니다. 이것은 다른 새로운 사람들에게도 그렇게 될 것이라고 확신하기 때문에 여러 번 저를 사로 잡았습니다. 이것이 최적화라는 것을 이해하지만 실제로는 매우 혼란 스럽습니다. 내 ts 파일에 무언가를 입력하면 단순히 무시하지 않고 생성, 출력 또는 어떤 종류의 것을 기대합니다. require 문을 강제로 생성 할 수 있지만 약간 엉망인 것 같습니다. 이것은 사용자로서 내가 컴파일러가 최선을 결정하지 않고 내 자신의 결정을 내릴 수 있어야하는 원인 인 것 같습니다.

TypeScript는 값 위에 유형 선언을 오버레이하므로 동일한 가져 오기 구문이 유형, 값 또는 둘 다를 가져옵니다. 이것은 모듈 작업을 매우 편리하고 직관적으로 만듭니다. 다른 모듈에서 유형이 필요한 경우 변수를 가져올 때 가져 오거나 클래스를 가져 와서 유형과 생성자로 모두 사용하십시오.

이것의 반대로, 존재하지 않는 모듈은 단지 타입 컨테이너이기 때문에 가져 오기를 할 수 있습니다. 컴파일러가 이러한 모듈에 대한 참조를 내 보낸 경우 런타임에 실패합니다. 우리가 가지고있는 해결책은 가져 오기가 사용 된 _how_를 감지하고 _all_ 참조가 유형으로 사용 된 다음 런타임에 필요하지 않고 제거되는 것입니다.

분명히 모듈의 부작용이 필요한 경우 혼란 스러울 수 있습니다. 그러나 다른 방법은 기존 모듈이 아닌 모듈에 대한 가져 오기가 생성 된 경우에도 혼란 스럽습니다. 동일한 구문에서 유형과 값을 함께 묶는 편의성을 잃어 버려야합니다.

해결 방법 :
기존 해상도 ( moduleResolution 가 node 설정되지 않음)를 사용하는 경우 식별자에 ! 가 포함 된 import 문은 절대로 빠져 나가지 않습니다. 나는 이것이 우리가 systemjs 동작을 더 잘 지원하려는 우리와 관련이 있다고 생각하지만 강제로 가져 오는 데 사용할 수 있습니다. systemjs, requirejs 또는 모듈 식별자를 다시 매핑 할 수있는 로더를 사용하는 경우 !js 또는 유사한 표시로 강제 가져 오기를 종료하고 모듈 로더로 매핑 할 수 있습니다. TS는 가져 오기를 그대로 내보내고 (유형 검사 나 해결을 시도하지 않음) 로더가 가져 오기를 이해하는 방법을 배울 수 있습니다.

팀은 이미 checker.ts와 같은 이러한 유형의 가져 오기에 대해 특수한 코드를 작성해야하는 것으로 보입니다.

// If we're compiling under --jsx react, the symbol 'React' should
// be marked as 'used' so we don't incorrectly elide its import. And if there
// is no 'React' symbol in scope, we should issue an error.
if (compilerOptions.jsx === JsxEmit.React) {
    let reactSym = resolveName(node.tagName, "React", SymbolFlags.Value, Diagnostics.Cannot_find_name_0, "React");
    if (reactSym) {
        getSymbolLinks(reactSym).referenced = true;
    }
}

@mhegazy가 지적했듯이 이것은 최적화에 관한 것이 아니라 런타임 오류를 유발할 수있는 런타임 정의 (예 : 인터페이스)없이 가져 오기를 요구하지 않는 것입니다.

나는 어떤 일이 더 자주 일어날 지 의문이다. 가져 오기가 * .d.ts인지 쉽게 감지 할 수 있으므로 쉽게 제거 할 수 있습니다.

나머지 경우에는 컴파일러가 가져온 모듈에 런타임 출력이 없다는 것을 감지하고 해당 가져 오기만 제거하는 것이 매우 사소한 것처럼 보입니다.

DRY 관점에서,이 제안은 당신의 트랜스 파일러가 저를 위해이 복제 된 코드를 작성할 수있는 트랜스 파일러가 있기를 바랍니다.

import * as React from "react"; // get the types
import "react";  // just for side effect

내가보기에, 런타임에로드해야하는지 여부는 _imported_ 파일의 선택이어야합니다 (부작용이 있음을 알고 있기 때문). 이것은 _loading_ 파일 (즉, import 문이있는 파일)에 의해 결정되어서는 안됩니다. 다른 파일 / 모듈의 구현 세부 사항을 아는 것은 업무가 아니기 때문입니다.

적어도 이것은 angularjs 관점에서 잘 작동 할 것입니다. 여기서 지시문과 서비스를 정의하는 파일은 참조되는 경우 런타임에로드되어야한다는 것을 "알고"있으므로 컴파일러가이를 제거해서는 안됩니다. typescript 컴파일러에 "제거하지 않음"에 대한 파일의 힌트가이 IMO를 수정합니다. 그러나 나는 아마도 여기서 일부 사용 사례를 간과하고있을 것입니다.

-JM

xmodule.ts :

console.log('ive been imported');
export class X {
}

import {X} from "xmodule"; // get the types
import "xmodule";  // just for side effect

xmodule에 명령문 (예 : console.log 명령문)이있는 경우 정의에 따라 선언 더미가 아닙니다. xmodule이 일련의 유형 선언 이상으로 간주되도록 xmodule을 사용하는 명령문을 만드는 것은 반입 모듈의 책임이 아닙니다.

뿡 빵뀨

강제로 가져 오기 위해 강타를 사용한다고 언급했습니다. 그것은 내 시나리오에 선호됩니다. 그래도 어떻게 사용합니까? 다음을 모두 시도했습니다.

!import {Service} from './service';
import! {Service} from './service';
import {!Service} from './service';
import {Service!} from './service';
import {Service} from '!./service';
import {Service} from './service!';
import {Service} from !'./service';
import {Service} from './service'!;

그것은 문자열에 있었지만 최근에 경로 매핑이 도입되었을 때 동작이 제거되었다고 생각합니다.

나는 노드 래퍼를 가져 오기 위해 react와 같은 라이브러리를 사용하고 있습니다.

import { h, Component } from "preact";

물론 런타임에는 h가 없습니다. 왜 거기에 있었을까요? 또한 jsx와 함께 사용하면 TypeScript는 실제로 h에 관한 것이 아니지만 babel은 알고 있습니다.

그래서 남은 것은 h와 같은 참조를 사용합니다. 수입 후, 네?

h (또는 다른 사용자 지정 jsx 팩토리)의 경우 --jsxFactory 를 사용하여 컴파일러에게 이것이 런타임에 사용중인 팩토리임을 알립니다. 예 : --jsxFactory h .

지금은 typescript@next 가 필요하지 않으며 TypeScript 2.1.2에서 사용할 수 있습니다.

@mhegazy 두 종류의 JSX 소비자 (예 : react 및 snabbdom)가있는 프로젝트의 경우 허용되지 않습니다.

웹 UI를 렌더링하는 데 반응을 사용하고 webgl 객체를 렌더링하기 위해 직접 구현 한 사용자 지정 가상 돔을 사용하는 프로젝트를 진행 중입니다. 그리고 동일한 프로젝트에 대해 두 가지 다른 종류의 @jsx 주석이 필요하기 때문에 코너 케이스에 도달했습니다.

이제는 우리 자신의 h 를 전역 변수로 내 보내야합니다.보기 흉합니다.

이 작업을 수행하는 단일 라이너 수입이 필요하거나 원하는 개발자 목록에 저를 포함 시키십시오. 이를 달성하기위한 두 줄의 소스는 특히 여러 모듈을 연속으로 가져 오려는 경우 제거하려는 것입니다. 지금까지 가장 잘 들리는 것은 가져 오기를 강제하는 키워드 / 구문이라고 생각합니다. 다시 한번 감사드립니다!