Typescript: Возможность перенапряжения TS и игнорирования конкретной ошибки разработчика

Созданный на 30 июн. 2016  ·  150Комментарии  ·  Источник: microsoft/TypeScript

Разработчик должен иметь возможность добавить комментарий над ошибкой ts, например

/// TS_IGNORE
let a:string = 1

и пусть компилятор не сообщит об этой ошибке ...
существуют определенные сценарии, которые разработчик знает лучше всего и хочет заглушить отчеты об ошибках.

вроде как: любой

С уважением

Шон

Fixed Suggestion

Самый полезный комментарий

Просто примените его (это не официальный термин, но та же концепция)

const foo: string = 7 as any;

Это то, что вы ищете?

Все 150 Комментарий

Согласовано. Тоска по чему-то вроде Java @SuppressWarnings , в частности, для случая, описанного здесь :

Следующий:

const typeMetadataKey = Symbol('type');

function type(name: string): PropertyDescriptor {
 return Reflect.metadata(typeMetadataKey, name);
}

Выдает ошибку: Unable to resolve signature of class decorator when called as an expression. .

При использовании, как показано ниже:

class Person {
  @type('string')
  firstName: string;
}

Декоратор работает должным образом и будет компилироваться, но выдает ошибку, указанную выше.

Если у вас есть мысли о том, как это можно решить, с радостью раскопайте его, если кто-то захочет указать правильное направление.

Просто примените его (это не официальный термин, но та же концепция)

const foo: string = 7 as any;

Это то, что вы ищете?

Я просто привел пример, не совсем случай (я все знаю о кастинге), у меня есть и другие случаи, такие как
super вызывается после первой строки конструктора и других проблем ...

  • упростит переход на TS с JS +, когда вы меняете библиотеку и получаете массу ошибок, и вы просто хотите все исправить, как вы знаете, как разработчик, по причине ...

это важная особенность

Так что-то вроде // tslint:disable ?
Возможно, даже позволить вам включать / выключать определенные проверки, которые выполняет tsc ?
_eg: _ const FooBar: string = 'rozzzly'; // tslint:disable-line camelcase

это было бы круто...

Я не знаю ... Я думаю, что это выходит за рамки tsc . Вот для чего нужен линтер.

там должна уметь "заткнуться" :)

Я думаю, есть аргументы в пользу подавления ошибок / предупреждений в «экспериментальных» функциях, таких как декораторы, где API немного изменчив, а ошибки не всегда могут быть точными. Вы получаете (очень конкретную) версию этого, просто используя поле tsconfig "experimentalDecorators", но оно подавляет только один тип предупреждений.

Чтобы сыграть своего собственного защитника дьявола, это могло бы побудить новых пользователей TypeScript подавлять предупреждения, которые они не понимают, вместо того, чтобы узнавать, почему возникает предупреждение. А с экспериментальными функциями каждый является своего рода новым пользователем - способность подавлять ошибки может заставить пользователей довольствоваться ошибками в новых функциях, а не открывать проблемы.

В конечном счете, я по-прежнему хочу, чтобы мой вывод Syntastic был чистым. Что означает подавление ошибки. Конечно, это будет _после__ я открою вопрос о возможной ошибке и попытаюсь узнать больше. ;)

Проблема с «заткнись» в том, что вы не знаете, что от «этого» получаете. так что let a:string = 1 a number или string ? Что, если есть другое объявление a , объединяется оно или нет? что, если кто-то захватил тип этой переменной, например, return {a} ; , должны ли они быть присвоены { a : number } или { a: string } , или обоим.

одна фундаментальная вещь, все ошибки неблагородны. ошибки не блокируют генерацию выходных данных или инструментарий.

Существуют различные механизмы, позволяющие подавить проверку определенных частей вашего кода, например, any , утверждений типа (приведения) и внешнего объявления.

так, например, если у вас есть библиотека с "недопустимым" определением, вы можете просто удалить ее и заменить на declare module "blah" { export = any } . или declare var $: any и все готово.

Поскольку я обычно отвечаю на эти запросы, думаю, ваша проблема не в подавлении ошибки. реальная проблема в том, что у вас есть ошибка, которую вы не находите полезной. подавление, которое не решает основную проблему, оно просто покрывает ее и вызывает несогласованное состояние без предупреждения. Правильное решение - знать, какую ошибку вы получаете? какая это библиотека? и почему компилятор выдает ненужную ошибку ...

А для этого нам нужно больше узнать о вашем варианте использования.

Мы проделали некоторую работу в TS 2.0, например, чтобы решить некоторые из этих основных проблем;

просто используйте любое, вот как "заткнись", достоинства этого (или на самом деле его отсутствие) - это другой вопрос

let x: PieInTheSky = <any> 'cake is a lie';

хорошо, но опять же, проблема не в литье

<any> дает вам ванильный javascript со 100% свободой от всех надоедливых вещей TypeScript, так что еще вам нужно?

в моем случае я называю super не первой строкой конструктора и мне нужно заглушить ошибку

Вместо того, чтобы пытаться заставить его принять антипаттерн, почему бы не написать, попробуйте что-нибудь вроде этого:

_ ClassA.ts _

class A {
    constructor() {
        this.init();
    }
    protected init() {
        // does nothing by itself
    }
}

_ ClassB.ts _

class B extends A {
    constructor() {
        super();
        console.log('rest of code from B\'s constructor');
    }
    protected init() {
        console.log('this runs before the rest of code from B\'s constructor');
    }
}

Это то, что делает машинописный текст таким замечательным, _и также раздражающим_. Это заставляет вас писать лучший код и делает вас лучшим разработчиком. Конвертировать проект - это не весело ; вы можете считать это «инициацией» разработчика или, возможно, «испытанием огнем». : смеясь: Но ты многому научишься, и это того стоит, имхо.

в моем случае я называю super не первой строкой конструктора и мне нужно заглушить ошибку

И сделать ваш код несовместимым с ES6 ... Именно поэтому основная цель TypeScript - вывести 👣: gun: из ваших рук.

Если TypeScript что-то неправильно интерпретирует, то это следует исправить, а не «обойти». Теперь есть несколько вещей, в которых TypeScript действует больше как линтер, и еще нет концепции «ошибка» по сравнению с «предупреждением». Я вижу подавляющие предупреждения, когда они приходят. На мой взгляд, такие вещи, как код после возврата и неиспользуемые параметры, должны быть предупреждениями, потому что они синтаксически правильные (хотя и глупые).

вот еще один случай, когда я хотел бы иметь эту функцию:

interface Animal {
  numberOfLegs: number;
  // a gazillion more properties
}

class Dog implements Animal {
  breed: string;

  constructor(animal: Animal, breed: string) {
    Object.assign(this, animal);
    this.breed = breed;
  }
}

Прямо сейчас есть ошибка ts:

[ts] Класс Dog неправильно реализует интерфейс Animal
Свойство numberOfLegs отсутствует в типе Dog.

Как видите, компилятор совершенно не прав, но я не хочу (и меня не следует принуждать) копировать все свойства из интерфейса только ради компилятора.

@DethAriel В основном то, что вы просите, - это способ выразить побочные эффекты условий публикации в системе типов. Это интересно, но я чувствую, что это приведет к ужасно запутанному коду.

@aluanhaddad Ага , я полностью понимаю. Но все же я не вижу неуверенного обходного пути для этого, за исключением копирования-вставки элементов интерфейса, что, по крайней мере, неидеально. Вот почему я думаю, что возможность отключать вывод ошибок компилятора имеет смысл - мы все здесь умные люди, и компилятор должен доверять нам, когда мы сообщаем об этом

Просто используйте комбинацию интерфейса + класса

interface Animal {
  numberOfLegs: number;
  // a gazillion more properties
}

interface Dog extends Animal {
}

class Dog  {
  breed: string;

  constructor(animal: Animal, breed: string) {
    Object.assign(this, animal);
    this.breed = breed;
  }
}

Спасибо ,

Что делать , если ошибка не может быть <any> эд прочь?

Я использую экспериментальный синтаксис связывания, как обсуждается здесь https://github.com/Microsoft/TypeScript/issues/3508, и, помимо того, что я его не использую, в противном случае я не могу заставить компилятор игнорировать ошибку в каждой строке перед каждым :: оператор ( TS1128: Declaration or statement expected )

Я использую экспериментальный синтаксис связывания

это действительно больше, чем отклонение одного предупреждения. Синтаксический анализатор не поддерживает это, поэтому результирующее дерево полностью неверно, все функции компилятора с этого момента не будут работать, поэтому без вывода типа, без проверок совместимости, без форматирования, без завершения, ничего. поэтому лучше игнорировать все ошибки или просто работать с файлом .js.

В настоящее время я конвертирую огромный проект JS в машинописный текст, и после выполнения преобразования, когда я запускаю команду gulp build я вижу около 2000 ошибок TS во время компиляции, и большинство ошибок связаны со свойством, не определенным в классе или модуле, не определенный. Я думаю, что должен быть какой-то способ подавить эти типы ошибок по мере создания выходных файлов JS.

Это как раз и мой случай, я конвертирую приложение, созданное с использованием дизайна модулей как свойств до ES6, поэтому у меня есть ОГРОМНЫЙ глобальный объект, похожий на app.namespace1.namespace2.something.views.view.

Я переписываю его часть и ДЕЙСТВИТЕЛЬНО полагаюсь на глобальный объект app. * И его различные подэлементы в моем коде. Все, что я получаю, - это масса предупреждений «Не удается найти приложение пространства имен».

Я реорганизовал все свои глобальные зависимости в globalProxy.ts, так что это единственное место, где я получаю предупреждения, но было бы УДИВИТЕЛЬНО добавить // TS-NO-WARNINGS вверху этого файла, чтобы очистить консоль. из очевидных сообщений ...

Ошибки TS не блокируют генерацию кода. Вы можете игнорировать их, но они говорят вам, что компилятор не может подтвердить правильность вашего кода.

@ zeeshanjan82, почему бы не использовать --allowJs и переносить файл за файлом? При такой настройке вы не получите ошибок типа из источников JavaScript. Вы также можете использовать объявление внешнего подстановочного знака для подавления ошибок разрешения модуля, таких как
_globals.d.ts_

declare module '*';

Вот еще один вариант использования подавления ошибок.

Сопровождающие библиотеку моментов забыли добавить isoWeek в качестве допустимой строки в перечисление параметров для методов startOf и endOf . Это было исправлено в следующем выпуске, но при этом они полностью изменили способ обработки этих модулей, что вызвало бы слишком много переделок с нашей стороны.

Итак, мы исправили версию момента, но теперь мы по существу не можем использовать isoWeek из-за ошибок выдачи TS. Так что сейчас застрял между камнем и наковальней.

вы можете просто добавить локальную копию. скажи что-нибудь простое, например:

// ./overrides/moment.d.ts
declare module "moment";
// tsconfig.json
{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es5",
        "baseUrl": ".",
        "paths": {
            "moment": ["overrides/moment.d.ts"]  // override definition for moment
        }
    }
}

теперь компилятор будет проверять вашу локальную копию override/moment.d.ts вместо той, что идет в пакете. очевидно, это может быть локальная копия файла объявления момента или небольшой набор вещей, которые вам нужны.

У меня нет ни времени, ни желания поддерживать свои собственные определения типизации для сторонних библиотек;)

У меня нет ни времени, ни желания поддерживать свои собственные определения типизации для сторонних библиотек;)

И это прекрасно. просто используйте declare module "moment"; что эквивалентно declare var $: any для модулей, и компилятор больше не будет беспокоить вас по этому поводу.

Предложение @mhegazy очень хорошее. На это у вас уйдет около 20 секунд. Кстати, что касается момента, они забыли пару модулей, которые я использовал, и были очень открыты для принятия моего запроса на перенос.

Обратной стороной добавления declare module "moment"; является то, что у вас больше не будет никакой IDE intellisense или проверки статического типа для любого кода, связанного с моментом. И возникающие any s имеют тенденцию просачиваться в окружающий код, закрывая также там многие статические проверки. Это высокая цена за подавление ошибок, связанных с одним проблемным значением перечисления.

@aluanhaddad был открыт запрос на isoWeek ), поэтому не уверен, что там произошло .

Дело в том, что эти проблемы неизбежно будут возникать чаще в будущем с принятием Angular 2 и т. Д., Поэтому я могу себе представить способ подавления определенных ошибок был бы полезен.

У меня проблема с базовой библиотекой узла (сеть, узел 6.9 LTS):

server = net.createServer({ pauseOnConnect: true }, function(connection) { ... }) 
// [ts] severity: 'Error'
message: 'Argument of type '{ pauseOnConnect: boolean; }' is not assignable to parameter of type '{ allowHalfOpen?: boolean; }'.
  Object literal may only specify known properties, and 'pauseOnConnect' does not exist in type '{ allowHalfOpen?: boolean; }'.'

А также с библиотекой ioredis:

var redis = new Redis(CONFIG.redis); 
// [ts] severity: 'Error'
message: 'Only a void function can be called with the 'new' keyword.'

Как указали @yortus и @adamreisnz , это распространенная проблема, поскольку файлы определений не всегда правильно обновляются. Кроме того, если вам нужно пожертвовать преимуществами TS, используя declare module "x"; зачем вам вообще использовать TS?

Вы также можете дополнить модуль недостающими типами, чтобы не потерять интеллект.

Хорошо, когда я пишу:

if (typeof Symbol === "function" && Symbol.match) {
  // ...
}

Компилятор машинописного текста всегда сообщает об ошибке Cannot find name 'Symbol' если target равно es5 , хотя этот код действительно работает так, как я ожидал.

Так что я согласен с тем, что нам очень нужны некоторые управляющие директивы, работающие в строках комментариев.

declare var Symbol: any;

@ gdh1995 @mhegazy Или просто используйте реальное исправление, которое устанавливает флаг lib на es2015 .

@mhegazy Спасибо. Я считаю, что это хорошо работает:

declare var Symbol: {
  (description?: anyNotSymbol): symbol;
  readonly match: symbol;
};

@DanielRosenwasser Хотя es2015 добавляет эти полезные функции, мой проект ограничен совместимостью с es5 а затем Symbol следует избегать в других файлах.

Сейчас я не понимаю, что компилятор TypeScript выдает ошибки, даже когда я написал typeof Symbol === "function" . Любой совет?

Один случай, который я хотел бы добавить, - это имитация зависимостей:

// Test.ts

// Component to test
import {ComponentToTest} from './ComponentToTest';

// Dependency of ComponentToTest to mock
import {Dependency} from './Dependency';

// Mock to replace it with
import {MockedDependency} from './MockedDependency';

Dependency = MockedDependency;

Этот код имеет желаемый эффект, заключающийся в имитации зависимости в тестируемом компоненте, но TypeScript выдает очевидное сообщение «Невозможно назначить« Зависимость », потому что это не переменная». ошибка.

Я уверен, что ответ будет заключаться в том, что я лаю не на то дерево и должен использовать что-то вроде inject-loader но, судя по моему опыту, эти решения A) сложно заставить работать / не всегда работа и Б) не так просты, как указано выше. Как упоминалось в OP, иногда разработчик знает лучше. Я знаю, что это хакерское решение, но оно работает, и я бы хотел, чтобы TS просто заткнулся в этом случае.

Этот код имеет желаемый эффект, заключающийся в имитации зависимости в тестируемом компоненте, но TypeScript выдает очевидное сообщение «Невозможно назначить« Зависимость », потому что это не переменная». ошибка.

это ошибка в ES6. так что когда-нибудь в будущем, когда движки будут поддерживать модули ES6 изначально, ваши тесты нужно будет переписать.

В качестве альтернативы вы можете сделать так, чтобы ваш ComponentToTest принимал аргумент для Dependency , и ваши тесты могут пройти это, или иметь тестовый крючок, который позволяет вам переопределить значение Dependency перед вызовом методов на ComponentToTest .

это ошибка в ES6. так что когда-нибудь в будущем, когда движки будут поддерживать модули ES6 изначально, ваши тесты нужно будет переписать.

Ах, честно, тогда я откажусь от этого, поскольку это требование не имеет отношения к этой проблеме.

В качестве альтернативы вы можете заставить свой ComponentToTest принять аргумент для зависимости, и ваши тесты могут пройти это ...

Я думаю, это то, к чему мы пришли. Это просто неубедительно - переопределять api для класса, чтобы сделать его тестируемым, но я думаю, что это вообще не проблема, уникальная для TS.

Спасибо за отзыв, @mhegazy

Я хотел бы отменить проверку типа аргумента функции.

Мой вариант использования довольно прост, у меня есть такая функция:

function isValidId(s: string): boolean {}

которые проверяют, следует ли строка какому-либо правилу.
Он используется как для внутренних целей, так и для проверки пользовательского ввода - я хотел бы написать тесты, чтобы увидеть, возвращает ли он false когда пользователь вставляет что-то, что не является строкой.

Строго говоря, функция может принимать что угодно в качестве входных данных, потому что может им управлять, но, поскольку мы используем ее также внутри, я хотел бы указать, что нам нужна строка

Поэтому хотелось бы что-то подавить ошибку о неправильном формате в тестах

@rpadovani просто используйте any :

expect(isValidId(78 as any)).toBe(false);

Я тоже мог бы это использовать. У нас есть ситуация, в которой foo (bar: any, baz: any) определяется как часть фреймворка, но в некоторых реализациях foo bar не используется. При включенной проверке ошибок машинописного текста возникает ошибка, поскольку объявляется неиспользуемая переменная. Он должен быть объявлен, потому что другие версии обув, используется бар.

@benjaminabbitt Похоже, что foo (_bar: any, baz: any) работает для вас: имя, начинающееся с "_" , не используется принудительно.

Дополнение: Я считаю, что важна возможность отменять / игнорировать особые ошибки.

Проблема в том, что люди продолжают говорить, что хотят подавить ошибки, публиковать фрагменты кода и получать эффективные встроенные решения для подавления этих ошибок (или выяснения, что у их кода действительно есть проблема). Трудно разработать эту функцию, не зная, как выглядит действительно проблемная ошибка, или не понимая, какие ошибки люди хотят глобально подавлять.

Каков подходящий способ обработки стороннего кода javascript, который мы хотим включить в наши проекты?

Рассмотрим следующий сценарий. Существует огромная библиотека, которая не была опубликована в npm, и даже если бы это было так, использование библиотеки как есть заставило бы наше приложение переносить много мертвого кода (встряхивание дерева не может помочь, потому что они прикрепляют все к объекту).

Предположим, что в этом случае просто не стоит извлекать этот кусок кода и публиковать в npm. Какие еще у нас есть варианты?

Пытаясь использовать эту библиотеку, я извлек код, который нужен моему проекту, и включил его в проект как файл машинописного текста. Проблема в том, что машинописный текст проверяет этот файл и теперь выдает много ошибок для этого файла.

В этой ситуации было бы здорово иметь комментарий /* ts:disable */ вверху, чтобы машинописный текст знал, что нас не волнуют возможные ошибки в файле.

Обратите внимание, что мой проект больше не фиксирует файлы javascript, и даже если бы это было сделано, процесс сборки усложнился бы, пытаясь разместить javascript в потоке.

Есть ли у кого-нибудь совет относительно того, как работать со сторонним кодом javascript, который необходимо разместить в проекте машинописного текста?

Есть ли у кого-нибудь совет относительно того, как работать со сторонним кодом JavaScript, который необходимо разместить в проекте машинописного текста?

не переносите их. оставьте файлы .js как есть. вместо этого создайте для них файл .d.ts. это то, что файлы .d.ts для любых способов.

файл .d.ts может начинаться с чего-то столь же простого, как:

declare var $: any;

затем добавляйте к нему по своему усмотрению и по мере роста ваших потребностей.

Это хороший вариант, если бы я фиксировал файлы js. Есть ли другие варианты для проектов, которые игнорируют файлы js?

Это хороший вариант, если бы я фиксировал файлы js. Есть ли другие варианты для проектов, которые игнорируют файлы js?

Я не уверен, что понимаю вопрос. По умолчанию файлы JS игнорируются. поэтому вы соглашаетесь на добавление файлов. Опять же, моя рекомендация: для внешнего кода, который не принадлежит вам, или для устаревшего кода, который вы не собираетесь изменять, не беспокойтесь о его преобразовании в TS. начните с написания для них файла .d.ts. для этого начните с простого, с any , затем добавляйте по ходу.

Я должен был сказать, что файлы js не фиксируются в репозитории git, что является причиной помещения кода в файл ts. В любом случае, я постараюсь пойти по указанному вами маршруту и ​​принудительно зафиксировать эти файлы js.

вам не нужно фиксировать файлы .js. скажем, вы используете зависимость, скажем, реагировать. обычно вы не будете фиксировать react-0.12.0.js в своем репо, но вы хотите его использовать. Обычно вы могли бы включить это, например, в тег сценария из CDN. допустим, @types/react не существует или вы не хотите его использовать. поэтому в вашем проекте добавьте новый файл декларации, назовите его declarations.d.ts и добавьте:

declare module "react"; // just saying the module is of type any

это сообщает компилятору, что существует модуль с именем «react», и он просто будет его использовать, без необходимости включать какие-либо файлы .js.

Поэтому, если я хочу использовать небольшой фрагмент javascript (который недоступен через npm / CDN), и я решаю зафиксировать его в своей базе кода, у меня есть 2 варианта:

Вариант 1. Сохраните исходный код в виде файла .js и сохраните файл .d.ts для обработки типов.

Я думаю, что это не работает для @ jmlopez-rod, потому что он не хочет фиксировать код javascript в своем репо, и даже если он это сделал, он сказал, что это усложнит его процесс сборки.

Вариант 2. Оберните javascript в машинописный текст и исправьте все ошибки машинописного текста.

Это позволяет обойти «сложный процесс сборки», потому что он будет обрабатывать код как машинописный текст ... но теперь у нас есть ошибки машинописного текста, и мы вернулись к исходному обсуждению в этой теме. Это допустимый вариант использования для отключения ошибок машинописного текста?

Я думаю, что это не работает для @ jmlopez-rod, потому что он не хочет фиксировать код javascript в своем репо, и даже если он это сделал, он сказал, что это усложнит его процесс сборки.

Не уверен, что понимаю, почему это усложняет процесс сборки. у вас есть файл "library.js" и "website.js" , вы решаете переместить "website.js" в "website.ts", просто вызываете tsc website.ts --outFile website.js и теперь мы вернулись туда, где все это начался с двух файлов .js. так что не понимаю, почему это сложнее, чем раньше .. это просто дополнительный шаг построения в начале цепочки.

Это позволяет обойти «сложный процесс сборки», потому что он будет обрабатывать код как машинописный текст ... но теперь у нас есть ошибки машинописного текста, и мы вернулись к исходному обсуждению в этой теме. Это допустимый вариант использования для отключения ошибок машинописного текста?

Я не уверен, что полностью понимаю, почему вы решили переключить этот файл на ts и интегрировать его со своим проектом, позволить типам из него перетекать в другие ваши компоненты, строить его вместе со своим кодом, но придерживаться другого стандарта.

Может быть, здесь будет полезен пример. как заметил @RyanCavanaugh , мне кажется, что у всех этих проблем есть четко определенные способы сообщить компилятору о типах и избежать ошибок вместо того, чтобы отключать ошибки все вместе и бросать ребенка с водой в ванну.

я не мог понять, почему это внешнее объявление не работает для меня.
Я уже определил определение путей к tsconfig.json, как это
"paths": { "js-xlsx": ["./xlsx.d.ts"] }
но все же я сталкиваюсь с тем, что модуль не найден.
Я попытался добавить библиотеки 'fs', 'fs-extra' и 'js-xlsx', все они не ответили на мои внешние объявления, кастинги или добавление каких-либо типов, как здесь declare var $: any;
@mhegazy

вам не нужно фиксировать файлы .js. скажем, вы используете зависимость, скажем, реагировать. обычно вы не будете фиксировать response-0.12.0.js в своем репо, но вы хотите его использовать. Обычно вы могли бы включить это, например, в тег сценария из CDN. допустим, @ types / response не существует или вы не хотите его использовать. поэтому в вашем проекте добавьте новый файл декларации, назовите его declrations.d.ts и добавьте:

объявить модуль «реагировать»; // просто говорю, что модуль имеет тип any
это сообщает компилятору, что существует модуль с именем «react», и он просто будет его использовать, без необходимости включать какие-либо файлы .js.

Кстати, я знаю, что библиотека fs-extra имеет определение типа, такое как @ types / fs-extra, а для js-xlsx у нас есть библиотеки ts-xlsx, но это настолько странно, что эти трюки у меня не работают :(

Кстати, я знаю, что библиотека fs-extra имеет определение типа, такое как @ types / fs-extra, а для js-xlsx у нас есть библиотеки ts-xlsx, но это настолько странно, что эти трюки у меня не работают :(

Я думаю, что с вашим проектом что-то еще происходит.

c:\test\9448>npm install @types/fs-extra
[email protected] c:\test\9448
`-- @types/[email protected]
  `-- @types/[email protected]

npm WARN [email protected] No description
npm WARN [email protected] No repository field.

c:\test\9448>type a.ts
import { rmdir } from "fs-extra";
rmdir("c:/test");

c:\test\9448>type tsconfig.json
{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es5"
    }
}
c:\test\9448>tsc --v
Version 2.2.0

c:\test\9448>tsc

c:\test\9448>echo %ERRORLEVEL%
0

да, возможно, но основная проблема, которую я не мог понять, - это почему я не мог подавить предупреждения компилятора с помощью данных методов. Кстати, у меня https://github.com/AngularClass/angular2-webpack-starter , база для моего проекта

Подавление ошибок не обязательно означает введение антипаттернов.

Я получаю неправильную ошибку,

error TS1005: '{' expected.

на этом прекрасном JSX:

<motor-node ref      = 'menu'
    absoluteSize     = `0, ${this.MENU_BAR_HEIGHT}, 0`
    >
    {menu}
</motor-node>,

Он жалуется, что для строки шаблона требуется { . В идеале это должно быть исправлено, но до тех пор я хотел бы иметь возможность подавить ошибку по уважительной причине .

@trusktr , это ошибка синтаксического анализа. подавление этого не меняет того факта, что компилятор не понимает код с этого момента, а форма остальной части файла находится в неопределенном состоянии. это означает, что даже если эта ошибка приглушена, предполагаемые типы, а также другие ошибки, сгенерированные в этом или других файлах, неверны.

Тем не менее. Согласно спецификации JSX :

JSXAttributeValue:

"JSXDoubleStringCharactersopt"
'JSXSingleStringCharactersopt'
{AssignmentExpression}
JSXElement

Поэтому я боюсь, что ошибка верна, и атрибут JSX не может иметь литерал строкового шаблона. вместо этого вы можете использовать absolteSize = {...}

эта ошибка является ошибкой синтаксического анализа

Ага, поэтому это нужно исправить.

На выходе получается absoluteSize: "0, " + this.MENU_BAR_HEIGHT + ", 0" , что говорит мне компилятору, что все в порядке.

Ой. Тогда извини. Я не понял ваш комментарий. Я думал, вы хотите, чтобы ошибка была отключена.

Я так и сделал, но вы правы, может мне лучше жить, просто добавив {} .

В TS 2.1 (VS2017 RC) мы получаем сообщения о предупреждениях из папки JS-файлов библиотек (находящихся в папке / Scripts), например TS7027. Было бы неплохо иметь возможность либо подавлять предупреждения / ошибки из файлов библиотеки, либо, по крайней мере, подавлять их в каком-то глобальном файле подавления (аналогично C # GlobalSupressions.cs)

В TS 2.1 (VS2017 RC) мы получаем сообщения о предупреждениях из папки JS-файлов библиотек (находящихся в папке / Scripts), например TS7027.

Для недоступного кода (TS 7027) установите --allowUnreachableCode или укажите его в своем tsconfig.json .

Но возможно ли это применить только к файлам библиотеки. Потому что для "моего кода" он мне нужен!

используя --alowJs он становится вашим кодом. компилятор втянет его, перенесет в предложенную цель, объединит его, если вы используете --outFile .. это просто расширение .js. если это «библиотечный» код, я бы рекомендовал создать для него .d.ts и вместо этого включить его.

Я не знаю, что мы включили --allowJs - в VS2015 точно такой же проект не искажает файлы jquery.js, react.js, находящиеся в скриптах (и фактически на него ссылаются только со страницы html,

let { value } = browser.waitForPromise(() => {
    return browser.executeAsync(function (method, name, resolve) {
        require(['patron.Locator/patron.Locator.Manager'], function (locator) {
            resolve(result);
        });
    }, method, name);
});

В моем случае первая строка написана на TypeScript, вторая строка написана на JavaScript. Они выполняются в разных контекстах, и я не хочу изменять код JavaScript.
Итак, нам нужен новый вариант, например /* ts-disable */ /* ts-enable */ (похожий на eslint)

В моем случае первая строка написана на TypeScript, вторая строка написана на JavaScript. Они выполняются в разных контекстах, и я не хочу изменять код JavaScript.

Не уверен, что понимаю, что вы имеете в виду под «второй строкой, написанной на JavaScript»? вы передаете компилятору весь оператор или нет?

Не уверен, что понимаю, что вы имеете в виду под «второй строкой, написанной на JavaScript»? вы передаете компилятору весь оператор или нет?

Я не хочу изменять этот код, потому что он должен быть передан на сервер Selenium как есть .

Я не хочу изменять этот код, потому что он должен быть передан на сервер Selenium как есть.

если он находится в файле .ts, он будет преобразован компилятором. Компилятор удаляет аннотации типов за вас.

Тем не менее, для этого примера все, что вам нужно, это declare var browser: any; и вы не должны получать никаких ошибок. см. « Игровая площадка» для образца.

если он находится в файле .ts, он будет преобразован компилятором. Компилятор удаляет аннотации типов за вас.

Мне нужна гарантия, что данный код выполняется без изменений в IE6 и других старых браузерах.
Например, Node.js следует модульной системе CommonJS, но моя require - это настраиваемая функция, определенная другими разработчиками на ее страницах. Вот почему я хотел бы включить этот код без каких-либо пост- и предварительных модификаций. Это важно для меня и моей команды.

Тем не менее, для этого примера все, что вам нужно, это объявить var browser: any; и вы не должны получить никаких ошибок. см. «Игровая площадка» для образца.

Собственно, объект браузера - самый популярный объект в моем проекте, и нет никаких причин игнорировать его. Метод browser.execute имеет собственное объявление типа.

Теперь я не уверен, что понимаю, в чем проблема. какую ошибку вы получаете?

Мой код выполняется в разных контекстах: узел и браузер. Текущие проблемы для второго контекста - это аннотации типов и модификация кода.

img-2017-03-07-02-10-28

let { value } = browser.waitForPromise(() => { // node
    return browser.executeAsync( // node
            function (method, name, resolve) { // browser
        require(['patron.Locator/patron.Locator.Manager'], function (locator) {  // browser
            resolve(result);  // browser
        });  // browser
    }, method, name); 
});

Вот простая реализация метода browser.executeAsync :

browser.executeAsync  = (...args) => {
   let script = args.shift();

   RPC.Selenium('/session/:sessionId/execute', {
         script: `return (${script}).apply(null, arguments)`, 
         args
    });
}

Как видите, я использую TypeScript для тестирования интеграции.

Что за сообщение об ошибке?

Стандартные ошибки:

TS2345: Argument of type 'string[]' is not assignable to parameter string
TS7006: Parameter 'error' implicitly has an 'any' type
TS7006: Parameter 'attach' implicitly has an 'any' type
TS7006: Parameter 'message' implicitly has an 'any' type
TS7006: Parameter 'model' implicitly has an 'any' type

И так далее...

Определите require правильно.

declare function require(v: string[]): any;

Правильно определите require.

Я не могу. В моем случае метод executeAsync содержит код для сторонних проектов, и существуют разные варианты для таких require s. Приведенный выше код - это всего лишь одна функция из сотен.
Мое желание очень простое - позвольте мне исключить какой-нибудь код, когда он мне понадобится :)

вы можете поместить declare function require(v: string[]): any; локально. например:

// module a.ts
export var ...

declare function require(v: string[], callback: Function);

let { value } = browser.waitForPromise(() => { 
    return browser.executeAsync( 
        function (method, name, resolve) { // browser
            require(['patron.Locator/patron.Locator.Manager'], function (locator) {  // OK
                resolve(result);  
            });  
        }, method, name);
});

при необходимости вы также можете просто привести к any :

let { value } = browser.waitForPromise(() => { // node
    return browser.executeAsync( // node
        function (method, name, resolve) { // browser
            (<any>require)(['patron.Locator/patron.Locator.Manager'], function (locator) {  // browser
                resolve(result);  // browser
            });  // browser
        }, method, name);
});

В результате должен получиться идентичный код.

В моем случае у меня есть частный (не экспортируемый) абстрактный класс, который предназначен только для расширения двумя классами:

abstract class IParent {
  static fromConfig(config: ParentConfig): IParent {
    // actual code is 20 lines long, not this simple
    // this throws "Cannot create an instance of the abstract class 'Parent'"
    return new this().applyConfiguration(config);
  }
  abstract method1(): void;
  ...
}

export class FirstChild extends IParent {
  specificMethodForFirstChild() { ... }
  method1() { ... }
  ...
}

export class SecondChild extends IParent {
  specificMethodForSecondChild();
  method1() { ... }
  ...
}

Использование:

let first = FirstChild.fromConfig({ ... });
let second = SecondChild.fromConfig({ ... });

// this runs successfully:
(first as FirstChild).specificMethodForFirstChild();
(second as SecondChild).specificMethodForSecondChild();

Но в методе fromConfig() я получаю сообщение «Невозможно создать экземпляр абстрактного класса Parent»:

Код игровой площадки

  • Я могу продублировать статические методы и заставить их вызывать общую функцию, но звучит глупо, когда у меня уже есть рабочий код.
  • Я не могу сделать класс не абстрактным, потому что подклассы применяют реализацию метода.
  • Я могу удалить абстрактные методы, но использую их для обеспечения того же интерфейса в подклассах.
  • Я могу использовать отдельный интерфейс, чтобы обеспечить его соблюдение, но тогда суперкласс не будет соответствовать интерфейсу, и это тип, возвращаемый статическим методом.
  • У меня нет намерения вызывать статический метод в абстрактном классе, я просто хочу, чтобы он создавал экземпляр другого класса в разных подклассах.

Компилятор не требует, чтобы конструкторы производного класса имели ту же сигнатуру, что и базовый. другими словами, конструктор производного класса может иметь больше требуемых аргументов, чем базовый. использование new this() предполагает, что все производные конструкторы не будут иметь обязательных параметров; и это то, что невозможно проверить.

Если вы уверены, что это правильно, рассмотрите возможность преобразования как new (<any>this)(x, y);

Хороший момент, я этого не видел. Ваше предложение действительно работает, я рассмотрю опасности, спасибо.

Есть ли способ заставить замолчать Module ... was resolved to ..., but '--allowJs' is not set ? в моем случае есть система сборки, которая позаботится об этом, и мне не нужно передавать весь свой код через TSC, поэтому я хотел бы заглушить эти ошибки.

'объявить модуль "someModule";' в одном из ваших файлов .d.ts.

Или установите соответствующий пакет @types , если он существует.

У меня есть еще один пример того, когда это будет полезно:

const Button = (
  content: contentTypes,
  action: React.EventHandler<React.MouseEvent<HTMLDivElement>>,
  disabled: boolean
): JSX.Element => (
  <div className={`Button disabled-${disabled}`} onTouchStart='' onClick={ !disabled ? action : undefined } >
    { content }
    <div className='background'></div>
  </div>
);

Это вызывает ошибку, потому что onTouchStart не принимает строку в качестве параметра, который является истинным. Однако onTouchStart='' исправляет некорректное поведение css на сенсорных устройствах, связанное с определенными правилами css. Я не хотел бы отключать эту ошибку глобально или переопределять некоторые типы JSX. Хотелось бы как раз в этой строчке убрать эту ошибку.

onTouchStart={<any>''}

На самом деле это не решает.
Я получаю такую ​​ошибку:
error
Это сломано под синтаксисом tsx

onTouchStart={'' as any} , скорее (забыл, что JSX использует альтернативный синтаксис утверждения)

Может ли сгенерированный код кодогенерацию swagger для создания клиента api для службы узла. Я также использую сгенерированные клиентские типы на своем сервере, поскольку он преобразует определения чванства в интерфейсы TypeScript, поэтому это самый простой способ убедиться, что я соблюдаю свой собственный контракт чванства.

Сгенерированный код выглядит немного странно, и в нем есть такие блоки:

let contentTypeHeader: Dictionary<string>;
if (contentTypeHeader) {
    fetchOptions.headers = contentTypeHeader;
}

Это дает ошибку, если strictNullChecks включен, поэтому я отключил этот флаг для всего проекта. Что отстой. Я не хочу анализировать сгенерированный машинописный текст и изменять его, но я был бы готов вставить что-то вроде <tsc strictNullChecks=false /> в начало файла (аналогично предложению @alexanderbird ).

Разве это не был бы запрос на изменение генератора кода чванства для создания кода, совместимого со strictNullChecks?

@mhegazy конечно - но это всего лишь один пример чего-то подобного. Есть много способов, которыми генерация кода полезна в TypeScript (больше, чем в JavaScript). Так что в идеале должен быть способ не заставлять людей снижать свои собственные проекты до стандартов их сгенерированного кода.

Но они есть :) код, который вы получаете из своего инструмента автоматической генерации, приводит к типам, которые переходят в вашу компиляцию. если инструмент генерации кода игнорирует --strictNullChecks тогда ваш код учитывает не вводящие в заблуждение типы.
отключение проверок просто заглушает пожарную сигнализацию. Дело не в тревоге, а в том, что в первую очередь вызывает пожар.

@mhegazy Я не

Как насчет менее спорного примера - что, если в сгенерированном коде есть неиспользуемый локальный адрес? Это не причиняет вреда моему коду - за исключением случая, когда мне нужно отключить noUnusedLocals в tsconfig - что я и делаю сейчас.

Как насчет менее спорного примера - что, если в сгенерированном коде есть неиспользуемый локальный адрес? Это не причиняет вреда моему коду - за исключением случая, когда мне нужно отключить noUnusedLocals в tsconfig - что я и делаю сейчас.

если вас не волнует сгенерированный код, то он должен быть в .js с сопутствующим .d.ts. таким образом вы можете проверить его, но не должны его компилировать.

компилятору машинописного текста, похоже, не нравятся миксины underscore.js, используемые с цепочкой.

_.mixin () {sortFunciton: sortFunc (), otherChainFunc: otherFunction ()}

....

someVal = _.chain (someArray)
.sortFunction ()
.otherChainFunc ()
.ценить();

...

Довольно простой пример - когда вы создаете прослушиватель для щелчка, например, с помощью @HostListener() для Angular, например:

@HostListener('click', ['$event'])
onClick(event: MouseEvent) {
    // Code here...
}

Если я включу noUnusedLocals , у меня будет следующая ошибка:

ERROR in ./src (20,13): 'onClick' is declared but never used.

В любом случае я могу позволить компилятору игнорировать это?

@JeremyCarlsten

_.mixin(){sortFunciton: sortFunc(), otherChainFunc: otherFunction()}

выглядит как недопустимый код.

@leocaseiro Почему это должно быть приватным? В этом случае onClick - это метод, который будет использовать angular. Подобная проблема всегда возникает, когда мы объявляем частные переменные, которые мы используем в шаблоне. Если вы все же используете их в шаблоне, просто сделайте переменные общедоступными. Это имеет смысл, поскольку вы позволяете angular использовать их.

Привет @ jmlopez-rod, ты прав.

Интересно, что как общественность, сейчас это проходит! Я действительно ценю твою помощь.

@leocaseiro public - это уровень видимости по умолчанию, поэтому указывать его не нужно.

Заранее извиняюсь, если звучит отрицательно - возможно, я что-то пропустил (новое для TS).
Другой пример (я использую TS только для создания ES5 - без приведения, объявления, взаимодействия)

// do-as-i-tell-you-start
const factory = () => {
  const _this = [];
  let _value;
  Object.defineProperties(_this, {

    // Error: Property 'getset' does not exist on type 'any[]'.
    // true at at creation but not when used – don't MOM me!
    'method1': { value(){ return _this.getset; } },   

    // Works with property strings – I don't want this
    'method2': { value(){ return _this['getset']; } }, 

    'getset': { get(){ return _value; }, set(value){ _value = value } },
  });
  return _this;
}

верно при создании, но не при использовании - не мама меня!

Именно для этого и предназначен TypeScript. Если вы не хотите использовать типы и приведение типов, почему вы используете TypeScript? Как неоднократно указывалось в этом потоке, он все равно будет выдавать код, поэтому вы уже игнорируете ошибки на свой страх и риск. Зачем пытаться приглушить TypeScript, с какой целью?

Зачем пытаться приглушить TypeScript, с какой целью?

Речь идет о перемещении команды с ES5 => ES6 (Babel или TS) => TS во всей красе - маленькими шагами.

У меня сложилось впечатление, что TS - это дополнение к JS, позволяющее вам определить, на каком уровне вы находитесь.
Причина моей жалобы - предоставленный фиктивный пример выдает ошибку и, следовательно, _does
не производить ES5_. Попутный линтинг IMO не должен быть обязательным для транспиляции.

Если у вас нет сообщения об ошибке, оно будет выдавать. Таким образом, он производит ES5.

Не получилось - переключился на Вавилон - сработало

tsc можно настроить на выдачу вывода независимо от ошибок типа, посмотрите на параметр noEmitOnError .

Если вы используете ts-loader, у него также есть новая опция transpileOnly которой он будет просто переноситься и не показывать никаких ошибок.

@trusktr спасибо - попробую :-)

ошибки не блокируют генерацию выходных данных, ни инструментарий

Это не правда. У нас есть (довольно распространенная - исходящая из стартера) установка в webpack, которая в производственной сборке дает сбой и ничего НЕ выводит. Так и должно быть - компилятор сообщает об ошибках, программист возвращается и исправляет их. Зачем использовать типы, когда вся команда игнорирует их, потому что сборка «работает»? Точно так же, если tsc не удается скомпилировать, автоматическое обновление не работает (плагин специально написан таким образом - он не обновляется, если ваш код неправильный [или компилятор считает его неправильным]).

Подавление ошибок полезно, когда есть ошибка в tsc. Например, это должно скомпилироваться:

interface A {
  isEmpty(x: any[] | string | object): boolean;
}

const a: A = <A>{};
a.isEmpty({a: 1});

но в текущем выпуске TS это не удается.

Изменить: исправлен вызов функции (скопирована неправильная строка)

К

a.isEmptyObject ({a: 1});

ты имеешь в виду

a.isEmpty ({a: 1});

?

О, да. Скопирована не та строка: /.

Подавление ошибок полезно, когда есть ошибка в tsc.

Исправлена ​​ошибка, препятствующая излучению. Маловероятно, что способность игнорировать ошибку может привести к тому, что tsc внезапно выдаст что-то, если в нем есть ошибка, которая приводит к сбою.

У меня есть импорт, который выглядит так:

import * as reducers from "./**/reducer.ts"

Сначала я использую TypeScript, затем Babel. У меня есть плагин babel, который обрабатывает * при импорте как шаблон глобуса. TypeScript выдает ошибку с жалобой на .ts , а затем, если .ts удаляется, он не может найти модуль.

Я не совсем уверен, как это решить, но моей первой мыслью было подавление ошибок, связанных с этой строкой. Я попытался выполнить сопоставление модулей в конфигурации, но * рассматривается как подстановочный знак и не может быть экранирован.

@lukescott в .d.ts в рамках компилятора:

declare module './**/reducer' {
  export = {
    [reducer: string]: () => void; /* or whatever */
  };
}

Еще один пример того, как это было бы полезно:

const req = https.request({
        host: 'www.google.com',
        method:'GET',
        path:'/',
        port: 443,
}, (res) => { 
    console.log(res.connection.getPeerCertificate());
});

getPeerCertificate говорит, что он не существует из-за ошибочных определений в узле https ( также это ).

Он по-прежнему компилируется и работает с большим красным подчеркиванием, но было бы очень неплохо сделать

console.log(res.connection.getPeerCertificate()); //ts:disable-line

@trusktr
Ой, похоже, я испортил синтаксис, преобразовав его из кода продукта. Вот часть того, что я пытался описать. Возможно, больше проблема с определениями подчеркивания. Но если сторонняя библиотека вызывает проблемы с компилятором ts, разве мы не можем игнорировать эту строку кода?

+1. Это будет полезно для тестирования, так как мне нужно убедиться, что мой код выдает ошибку, когда он передается во что-то, чего он не ожидает.

Эта полезная функция была бы просто обобщением ! для возможно нулевых объектов.

Если я хочу добавить файл библиотеки в проект (например, Chartjs), я часто сохраняю его как файл TS (мне нравится сохранять все исходные файлы как TS и компилировать как JS) и импортировать его с тройной косой чертой ref в TS файл, который требует этого. Однако TypeScript затем бесконечно жалуется на ошибки в этом файле (естественно, поскольку это просто стандартный файл JS, сохраненный как TS).

Однако возможность добавить:

/*ts-errors-disable*/ до начала файла библиотеки и /*ts-errors-enable*/ до конца уменьшили бы вывод ошибок, которые не имеют отношения к делу, но все же позволяют разработчикам сохранять все исходные файлы как TS.

Или мне просто нужно делать что-то принципиально по-другому?

@benfrain Ну, было бы лучше установить соответствующий файл определений TypeScript, если он существует ( npm install --save-dev @types/mylibrary ), или создать свой собственный файл _.d.ts_ с типом any в пространство имен вашей библиотеки / основной класс первый:

// mylibrary.d.ts
declare module "mylibrary" {
    let mylibrary: any;
    export = mylibrary;
}
// main.ts
import mylibrary = require("mylibrary");
...

У меня вопрос. Сначала код и ошибка, которую выделяет TypeScript:

import {Directive, ElementRef, Input, OnChanges, SimpleChange} from '@angular/core'

@Directive({
  selector: '[blankAttr]',
})
export class BlankAttr implements OnChanges {
  @Input('blankAttr') private attrName: string // <--- TS Error: unused variable

  constructor(private el: ElementRef) {}

  public ngOnChanges(changes: {[key: string]: SimpleChange}): void {
    const change: any = changes.attrName 
    const prevValue: any = change.previousValue

    if (prevValue) {
      this.el.nativeElement.removeAttribute(prevValue)
    }
    this.el.nativeElement.setAttribute(change.currentValue, '')
  }
}

У меня проблема в том, что мне нужно объявить декоратор @Input чтобы атрибут мог передавать строку. Но меня волнует только значение этой строки, когда она изменяется. И я могу получить предыдущее и текущее значение при обработке события изменения.

Можно нам // ts-ignore сейчас? Или есть другой способ решить эту проблему?

@uglow, почему attrName закрыто ? Это переменная, которую Angular модифицирует, чтобы вы могли получить с ее помощью значение. Таким образом, он должен быть публичным.

@ jmlopez-rod Я изменил его на публичный, но это не меняет проблемы. TS говорит, что это неиспользуемая переменная.

Я использую TS 2.4.1, после того, как он стал общедоступным, машинописный текст перестает выдавать ошибку.

До:
screen shot 2017-07-26 at 9 53 13 am

После:
screen shot 2017-07-26 at 9 53 39 am

Пользуюсь 2.3.3. Я попробую 2.4.1. Спасибо 😊

Это должно быть включено. Я работаю с пользовательским движком js, который позволяет одному файлу .js возвращать значение. См. Мою суть для примера . Я использую TS для генерации моих файлов .js, и, конечно же, TS не знает об этом и выдает:

A 'return' statement can only be used within a function body.

Новый вопрос SO, который должен подавить ошибку noUnusedLocals :
https://stackoverflow.com/questions/45519476/is-it-a-typescript-antipattern-to-dynamically-call-a-member-function-stored-in-a

@mhegazy Я столкнулся с этой проблемой разными способами.

Моя текущая ситуация (весь поток предполагает режим объявления):

  • Для декораторов классов требуется объявление класса (а не выражение класса), и я нахожусь внутри функции - в принципе это можно исправить, но не сегодня.
  • хорошо, без проблем, я сделаю выражение декларацией
  • нет кубика, у объявления теперь неиспользуемое имя
  • хорошо, без проблем я верну
  • нет кубиков, Return type of public method from exported class has or is using private name
  • ...?

По сути, основная причина здесь в том, что выражения не могут быть украшены, но для вас неразумно отказываться от всего, чтобы реализовать эту функциональность. А пока для меня имеет смысл просто подавить эту ошибку. Я был бы в порядке, если бы для подавления ошибки мне потребовалось найти связанную проблему TypeScript и сказать что-то вроде // TS-LIMITATION:#9448 хотя я подозреваю, что с вашей точки зрения это приведет к огромному количеству новых бессмысленных проблем.

Я бы даже был в порядке, если бы вы добавили конкретные целевые подавления для известных проблем, к которым вы еще не готовы, но только если это было сделано быстро и без особых усилий при проектировании (это сделало бы механизм бессмысленным: wink:)

Я не хочу получать ошибку недостижимого кода (где я с радостью отмечаю «заткнись при ошибке недостижимого кода прямо здесь»), когда я делаю что-то вроде
if (false){ ...complicated debug code that I dont want to delete/forget... }

Итак, в компиляторе TypeScript все еще отсутствует возможность «заткнуться и не испортить другие инструменты». Для нас было бы действительно полезно иметь эту опцию через комментарии и через переключатели компилятора для определенных файлов или даже глобуса. Мы застряли в использовании старых версий инструментов, потому что не хотим терять автоматическую перезагрузку (новые версии не перезагружаются автоматически при наличии ошибок). Таким образом, мы либо отключаем опцию noImplicitAny с ошибками (чего я действительно не хочу, я использую TypeScript из-за проверки типов и с разрешенным неявным любым TypeScript не так много в таблице), либо остаемся на старых версиях пакетов. Да, я сообщил об ошибке как в загрузчике WebPack, так и в AwesomeTypeScript , но никого это не волнует. Вопрос игнорируется уже много месяцев. Я вижу, что то же самое и с пакетом TypeScript :-(.

@polyglotinc if (!!false) {

@RyanCavanaugh Ну, если уж на то пошло, (!true) работает ... Я даже не думал об этом как о возможностях, потому что я _ (как бывший компилятор-писатель) _ дал компилятору больше уважения в отношении константы / литерала свертывание выражения ... Думаю, я подумал, что если это будет занятое тело о if (false) , оно будет знать, что if (!true) - это то же самое!

@unional вопрос SO можно было бы написать немного яснее, и, возможно, именно поэтому нам нужно, чтобы компилятор сообщал нам о возможных ошибках. См. Этот снимок экрана, показывающий ошибку, которую пользователь хочет подавить.

screen shot 2017-08-09 at 12 43 20 am

Обратите внимание, что на скриншоте только одна ошибка. Это потому, что я уже исправил одну проблему, обнаруженную компилятором.

private keyHandlers = {
    'ArrowDown': function ($event: any) {
      this.handleArrowDown($event);
    },
    'ArrowUp': ($event: any) => {
      this.handleArrowUp($event);
    },
  };

Пользователь утверждает, что используются handleArrow* , но машинописный текст не видит, что они используются. Что касается машинописного текста, то this в this.handleArrowDown($event); может быть любым объектом, имеющим метод handleArrowDown . С помощью функции стрелки теперь он знает, что this является экземпляром класса, и поэтому видит, что используется handleArrowUp .

Другой вариант: используйте поддельный первый параметр this .

  private keyHandlers = {
    'ArrowDown': function (this: SomeComponent, $event: any) {
      this.handleArrowDown($event);
    },
    'ArrowUp': ($event: any) => {
      this.handleArrowUp($event);
    },
  };

@ jmlopez-rod Спасибо. Это хорошая альтернатива. Мне особенно нравится решение function(this: SomeComponent, ...) {...} потому что оно наиболее гибкое.

Стрелочная функция не работает, если keyHandlers не является частью класса:

const keyHandlers = {
  'ArrowDown': function (this: SomeComponent, $event) {
    this.handleArrowDown($event); // error on accessing private method, filing an issue for it.
  },

  'ArrowUp': ($event) => { // doesn't work, duh
    this.handleArrowUp($event);
  }
}

export class SomeComponent {
  onKeyDown($event) {
    if (typeof keyHandlers[$event.code] === 'function') {
      keyHandlers[$event.code]($event);
    }
  }
  private handleArrowDown(_event) {
    // ...
  }

  private handleArrowUp(_event) {
    // ...
  }
}

С другой стороны, стрелочная функция в этом контексте является наиболее простой.

Я пытаюсь вручную установить window.console для IE9, чтобы предотвратить ошибки при использовании console.log :

if (!window.console)
    window.console = {};

Но я получаю error TS2540: Cannot assign to 'console' because it is a constant or a read-only property. Есть ли обходной путь для этих случаев использования?

@amiraliakbari Вы можете утверждать window как тип any , что позволяет отказаться от проверки типа:

(window as any).console = {};

это сработало для меня, чтобы переопределить / отключить console.log глобально - обратите внимание, что Project.logging был определен до этого

(window.console as any).___real_log = window.console.log;
window.console.log = function(args) {
  if (Project.logging) return (window.console as any).___real_log(args);
  return;
};

Это также было намного чище, чем размещение операторов if всему моему коду, поскольку я могу просто использовать console.log как обычно

Как упоминалось в # 19109, у нас все еще нет возможности подавить конкретную ошибку.

Как упоминалось в # 19109, у нас все еще нет возможности подавить конкретную ошибку.

Я думаю, что основной сценарий, изложенный в этом вопросе, был рассмотрен. мы можем создать новую задачу для отслеживания глобального подавления ошибок, используя номер ошибки. Мы неохотно использовали коды ошибок таким образом, потому что им не хватало выразительности.

Создан №19139.

Эта инструкция работает только для каждого файла, не так ли? Можно ли заставить работать над папкой?

Предполагается, что инструкция работает для одной строки за раз. Если вы видите много ошибок компилятора в своем проекте, вы можете проверить, что у вас должны быть менее строгие параметры компилятора , такие как отключение noImplicitAny (т. Е. Переменные неявно равны any если нет аннотировано). Вы также можете оставить некоторые файлы как JS и включить allowJs но выключить checkJs .

Почему вы закрыли этот выпуск? Решение все еще отсутствует! Почему вы ведете бессмысленные дискуссии в течение 2 лет вместо того, чтобы интегрировать надлежащую возможность подавления ошибок?

@ webia1 Возможно, вас заинтересует # 19139, который все еще открыт.

(Добавление этого комментария здесь, поскольку он может быть полезен для тех, кто наткнулся на эту проблему, как и я)

Я наткнулся на https://github.com/Microsoft/TypeScript/pull/21602, и это могло быть решением.

Просто добавьте // @ts-ignore в свой код (или даже // @ts-ignore <some code error> чтобы игнорировать только указанную ошибку) .

Протестировал здесь с TypeScript 2.7.2, и он работает!

(или даже // @ ts-ignoreигнорировать только указанную ошибку).

21602 не был объединен. Нельзя игнорировать только определенные ошибки.

@RyanCavanaugh , ты прав! Я обновил свой комментарий. Спасибо!

Приехал сюда, чтобы погасить ошибку TS2339.

document.getElementById('theme-admin').disabled = false; /* tslint:disable */
document.getElementById('theme-member').disabled = true; /* tslint:disable */
Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

jbondc picture jbondc  ·  3Комментарии

wmaurer picture wmaurer  ·  3Комментарии

DanielRosenwasser picture DanielRosenwasser  ·  3Комментарии

weswigham picture weswigham  ·  3Комментарии

kyasbal-1994 picture kyasbal-1994  ·  3Комментарии