нужно это, лол

Текущий вариант использования этой функции — модульный тест, который работает с пробелами. В нашей кодовой базе включено правило «без конечных пробелов» по ​​уважительной причине, но невозможность обойти его на блочном уровне означает, что мы не можем легко проверить конечные пробелы и возврат каретки с помощью строки шаблона ES6. .

один из моих вариантов использования пользовательского связывания _ a.k.a partial import _ в mathjs

// tslint:disable:no-var-requires
import core from 'mathjs/core'

// @ts-ignore
import mathUnit from 'mathjs/lib/type/unit'
// @ts-ignore
import mathExpression from 'mathjs/lib/expression/function'
// @ts-ignore
import mathArithmatic from 'mathjs/lib/function/arithmetic'


const math = core.create()
// math.import(require('mathjs/lib/type/unit'))
// math.import(require('mathjs/lib/expression/function')) // compile, eval
// math.import(require('mathjs/lib/function/arithmetic')) // basic arithmetic like divide, exponent, etc

math.import(mathUnit)
math.import(mathExpression) // compile, eval
math.import(mathArithmatic) // basic arithmetic like divide, exponent, etc

export const unit = math.unit
export const createUnit = math.createUnit
export const compile = math.compile

Я хотел бы игнорировать ошибки для всего файла. Я унаследовал некоторый JS-код ES6, который я хотел бы транспилировать в ES5, но в данный момент должен использовать Babel. Было бы неплохо просто переименовать файл в .ts и транспилировать с помощью TS.

@ptallett , вы можете просто скомпилировать файлы .js , используя allowJs и включив их в компиляцию. По умолчанию мы не выдаем ошибки в файлах .js , если файл не имеет комментария // @ts-check вверху или вы не включили checkJs .

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

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

Было бы здорово, если бы везде не было кучи красных линий. :)

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

Использование lodash и особенно lodash/fp с TypeScript очень болезненно, и даже с последними версиями lodash и @types/lodash вы можете получить очень загадочные сообщения об ошибках.

Если бы мы могли иметь @ts-ignore-block , который игнорирует ошибки для следующего блока, это было бы здорово для таких случаев использования, когда _вы знаете, что делаете_ :-)

Я работаю с устаревшим кодом с многочисленными глобальными переменными, и писать @ts-ignore в каждой строке становится утомительно, какие-либо обновления по этому поводу?

Также ищет обновления по этому запросу. Спасибо!

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

с подавлением файла отверстия это можно было бы добавить в редакторы, такие как vs code, для сохранения в настройках рабочей области или тому подобном.

Тоже нужно это. Я автоматически генерирую целый файл ts с типами для моей схемы GraphQL, используя graphql-code-generator , и есть посторонний импорт, вызывающий noUnusedLocals.

/* tslint: отключить */

код

/* tslint:включить */

// @ts-ignore-start
// @ts-ignore-end

Можно комбинировать с: https://github.com/Microsoft/TypeScript/issues/19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

@marianturchyn это не tslint.

Иногда, когда я перемещаю вещи и рефакторинг, я хочу временно игнорировать весь файл (т. е. не компилировать его), не возясь с параметрами CLI.

Самый быстрый/самый простой - это флаг в верхней части файла:

// @ts-ignore-file

@ lonix1 Случай использования покрывается:

// @ts-ignore-start
// @ts-ignore-end

Вам не нужно использовать часть // @ts-ignore-end . Так работают многие инструменты lint.

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

@lonix1 Я имел в виду, что предложение @Blanen также сработает для вас, нам не нужен TypeScript для реализации // @ts-ignore-start + // @ts-ignore-end и // @ts-ignore-file , реализуя // @ts-ignore-start + // @ts-ignore-end будет достаточно. Это не реализовано, поэтому этот вопрос остается открытым.

@DanielRosenwasser это будет работать только тогда, когда файлы ts сохраняются в другой папке во время сборки. когда проект настроен на размещение файлов js рядом с файлами ts, он не будет. Также будут ли файлы js «скомпилированы», например, преобразованы в es5? При транспортировке унаследованного кода это было бы действительно полезно.

Нужна эта функция.

Вариант использования:

TypeORM ожидает, что мы создадим классы сущностей БД, у которых есть столбцы, которые могут или не могут быть нулевыми. Многие столбцы (следовательно) не могут принимать значения NULL… и, следовательно, должны рассматриваться, за исключением определения класса, как если бы свойства безусловно принадлежали определенным определенным типам. Однако Typescript требует, чтобы мы определяли каждый столбец как строго типизированный. Следовательно, мы получаем очень много сущностей, таких как:

@Entity('investigation')
export class InvestigationEntity {
    @PrimaryGeneratedColumn('uuid')
    // @ts-ignore TS2564
    public investigationId: string;

    @Column({ type: 'uuid' })
    // @ts-ignore TS2564
    public userId: string;

    @Column({ type: 'jsonb' })
    // @ts-ignore TS2564
    public metadata: IEncryptedJSONContainer;
}

Каждый столбец обязателен и (следовательно) обязательно должен содержать значение, но из-за того, как работает TypeORM, каждое свойство должно быть определено таким образом, чтобы в нем не было инициализатора. Было бы чрезвычайно удобно иметь возможность подавить эту конкретную проблему, связанную с ORM, для всего класса (следовательно, или файла).

@haggholm есть причина предпочесть ts-ignore public metadata!: IEncryptedJSONContainer ?

@RyanCavanaugh Невежество! Я пропустил эту функцию в документации. Извиняюсь; пожалуйста, игнорируйте.

я хотел бы сделать

// @ts-игнорировать-старт
--strick нулевые проверки для одного конкретного файла

Вот как выглядит юнит-тестирование приватных полей и методов с машинописным текстом. У меня есть 6 строк, посвященных игнорированию кода. Ужасный. Заставляет мои глаза кровоточить. Любые обходные пути для игнорирования блоков будут высоко оценены.

it('TestNode_ReconnectionsWorkload', async function () {
    for (let i = 0; i < 1; i++) {
        nodes.push(await Node.NewNode(serverUrl, {
            handlers: {
                active: async function (n: Node) {
                    try {
                        // @ts-ignore
                        if (n.view.Empty()) {
                            // @ts-ignore
                            if (n.conns.Empty() && !n.server) {
                                // @ts-ignore
                                await n.login(n.address);
                            }
                            return;
                        }

                        const data = new flats.Message({
                            // @ts-ignore
                            id: n.id,
                            type: flats.MessageType.Data,
                            data: 'hello world',
                        });

                        const dataBytes = data.toBytes();
                        const dataBase64 = base64.encode(dataBytes);
                        // @ts-ignore
                        const dataSigBytes = await n.sign(dataBytes);
                        const dataSigBase64 = base64.encode(dataSigBytes);

                        // @ts-ignore
                        for (const conn of n.conns.Iter()) {
                            conn.Send(`${dataBase64}.${dataSigBase64}`);
                        }
                    } catch (error) {
                        console.log(error);
                    }
                },
            },
        }));
    }

    for (const node of nodes) {
        await node.Wait();
    }
});

Ну, я собирался добавить новую проблему, но я думаю, что эта проблема охватывает ее.

@ts-ignore обрабатывает многострочный и однострочный импорт по-разному!

Есть еще много модулей npm, которые не имеют типизации или написаны без NoImplicitAny,
что приводит к ошибке «неявно любая», после чего они импортируются:

import { a, b } from 'MyNonTypedModule' // <-- Implicit any error

Поэтому я могу использовать @ts-ignore:

//@ts-ignore
import { a, b } from 'MyNonTypedModule'

Но когда я работаю с автоматическим импортом и форматировщиками, такими как Prettier, это происходит:
(отформатировано Prettier)

//@ts-ignore
import { 
  a, 
  b 
} from 'MyNonTypedModule' // <-- Still (again) getting the Implicit any error

Я могу исправить это с помощью:

import { 
 a, 
 b
//@ts-ignore
 } from 'MyNonTypedModule'

или

//@ts-ignore-start
import { 
   a, 
   b
} from 'MyNonTypedModule'
//@ts-ignore-end

Но затем это начинает выглядеть так при однострочном импорте:

//@ts-ignore-start
import { a } from 'MyNonTypedModule'
//@ts-ignore-end
import { b } from 'SomeTypedModule'
//@ts-ignore-start
import { c } from 'SomeOtherNonTypedModule'
//@ts-ignore-end

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

Было бы хорошо не писать ts-ignore-start и ts-ignore-end при каждом импорте,
Итак: //@ts-ignore для импорта (а не только следующей строки), на мой взгляд, это то, что должен обрабатывать ts-ignore. (Или какой-то другой игнор, например: @ts-ignore-block / @ts-ignore-import)

мне нужно подавить определенные ошибки во всем файле:

// @ts-ignore-all TS1206

/*
... rest of the file
*/

В согласии с людьми выше, которые предложили комментарии // @ts-ignore-start и // @ts-ignore-end для обработки вариантов использования, упомянутых в этой теме.

Это хорошо, потому что очень похоже на текущую директиву // @ts-ignore и позволяет вам игнорировать все ошибки в файле с помощью директивы // @ts-ignore-start вверху.

Есть положительные варианты использования для ряда вышеперечисленных предложений. Я предлагаю:

@ts-ignore как настоящее поведение
@ts-ignore TSxxx [TSxxx ...] подавить определенные ошибки
@ts-ignore-start начальный блок для игнорирования
@ts-ignore-start TSxxx [TSxxx ...] подавить определенные ошибки для блока
@ts-ignore-end конечный блок
@ts-ignore-all подавить ошибки для остальной части файла
@ts-ignore-all TSxxx [TSxxx ...] подавить определенные ошибки для остальной части файла

«Конкретные ошибки» могут включать в себя именованные группы, аналогичные группам в tsconfig, или определяемые пользователем группы ошибок TSxxx.

Я не уверен в значении блоков игнорирования, вложенных в импортированные модули; я бы предпочел явные блоки ts-ignore в импортированных файлах модулей. Но при импорте сторонних библиотек могут быть причины для этого, поэтому я здесь на заборе.

нужен файл .tsignore

так же, как .npmignore и .gitignore

Должен быть блок игнорирования. Я застрял в фреймворке puppeteer. В puppeteer у вас есть метод «оценить», который позволяет вам запускать произвольный блок скрипта на странице. Этот произвольный блок скрипта может содержать ссылку на функции, доступные на странице, другими словами, ссылка на функцию будет доступна во время выполнения.

// @ts-ignore-start
// @ts-ignore-end

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

О

// @ts-ignore-start
// @ts-ignore-end

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

это круто со мной

// @ts-ignore-begin
// @ts-ignore-end

Крайне необходимый функционал.

Почему это до сих пор невозможно? :-(

Мне тоже нужен игнор блока

+1

+1

какие-либо обновления по этому поводу?

🙏🏻

А если мы сделаем это так же, как обычно делаем с eslint?

/* @ts-disable */

!function(){
  // no ts here!
}()

/* @ts-enable */

Как упоминалось выше: как только вы генерируете код TS (например, с помощью swagger), где, например, могут возникнуть неиспользуемые переменные, вам нужна эта функция.

+1

Без //@ts-ignore-file невозможно мигрировать на TS

Так что это "никто не заметит" неправда

@RyanCavanaugh Сообщество явно нуждается в этом, есть ли причина, по которой это не было решено? Спасибо!

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

В настоящее время мы нуждаемся в этой функции.

Мы импортируем общедоступную библиотеку, которая имеет типы Node для некоторых функций, которые нам не интересны. Поэтому было бы неплохо использовать // @ts-ignore для одного импорта вместо использования skipLibCheck для игнорирования все библиотеки.

Сначала мне понравилась идея // @ts-ignore-file, но // @ts-ignore, вероятно, сработал бы лучше для согласованности.

Итак... Я открыл #33383 с поддержкой //@ts-nocheck в машинописных файлах. Теперь, когда мы являемся командой компилятора _TypeScript_, мы сами этого не понимаем (не исправляя вероятные проблемы, чтооооо!!?!?) - даже //@ts-ignore в машинописном тексте стали вещью только потому, что нам выкрутили руку немного, так что мы.... колеблемся... добавлять дополнительные механизмы подавления. Так что, если вы действительно чувствуете, что нужен такой широкий механизм подавления, было бы неплохо, если бы вы могли пойти туда и 👍

@weswigham , хотя это, вероятно, не самая важная функция. Это может быть удобно во время разработки. Точно так же, как временное комментирование нескольких строк кода, это может быть полезно при разработке и попытке локализовать проблему в другом месте. Однако я хотел бы получить предупреждение, чтобы эта практика не нашла способ вызвать ошибки во время выполнения. Возможно, даже включить эту функцию только для разработки, но чтобы выдавать ошибку при сборке.

Поскольку эта проблема по-прежнему помечена как "Ожидает отзывов", вот еще:

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

Добавить какой-нибудь комментарий @ts-ignore- вверху каждого файла было бы достаточно просто.

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

@weswigham Вы можете поместить это за флагом компилятора.

Вы можете поместить его за флагом компилятора.

Не надо - это в бете 3.7.

re: https://github.com/microsoft/TypeScript/pull/33383 : @weswigham , это здорово, спасибо! Мощным вариантом использования здесь является временное игнорирование проверки типов в файле, поэтому я предлагаю также отправить правило lint, которое не работает, когда кто-то забывает удалить @ts-nocheck

Возникла проблема с gatsby, где статический запрос graphQL работает в файлах .jsx , но не в файлах .tsx . Я думаю, что это предложение может быть более приемлемым обходным путем. (вопрос здесь https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5)

Привет!
Было ли реализовано предложенное решение?

// @ts-игнорировать-старт
// @ts-игнорировать-конец

Думаю, это было бы очень выгодно. Я был бы не против поработать над этим.

Мы добавили поддержку //@ts-nocheck для подавления всех ошибок во всем файле в версии 3.7. Я думаю, что подавление на уровне строк и файлов может охватывать _большинство_ потребностей без особой суеты. Если у вас есть достаточно большой блок в проверяемом файле, который следует не проверять, возможно, просто отключите проверку всего файла или, если это неприятно, извлеките непроверенный фрагмент в отдельный файл и отключите проверку этого файла или, в противном случае, подавить каждую строку с актуальной проблемой? Предполагается, что ts-ignore игнорирует одну проблему, в то время как ts-nocheck должен игнорировать один файл — подавление на основе диапазона на самом деле никоим образом не сопоставляется с конкретной единицей, поэтому кажется как-то хуже (поскольку это не может быть сопоставлено с одной проблемой или основной причиной, которую вы подавляете). По крайней мере, без подавления конкретных кодов ошибок мне не особенно удобно подавление на основе диапазона.

Я, по крайней мере, предпочел бы одиночное подавление ( //@ts-nocheck File is a legacy untyped UMD module concatenated into the build - declarations are pulled from node_modules, so errors here are hopefully meaningless ) в верхней части файла или отдельные подавления ( //@ts-ignore The TS compiler doesn't support the assignment on the next line because we never declare it, but we provide this for legacy compat ) для каждой отдельной плохой вещи (tm). Я не могу, хоть убей, придумать убедительный, принципиальный пример, где определенные _диапазоны_ кода должны быть разрешены непроверенными (в отличие от файлов, которые имеют четкую аргументацию, основанную на стратегии миграции), кроме как "написание нескольких последовательных от подавления у меня глаза кровоточат», к чему у меня _нулевое_ сочувствие, поскольку, по сути, мы считаем, что вы вообще не должны использовать подавления в TypeScript. Если это проблема типа, вы можете отказаться от нее (вот почему существуют any , приведение и сокращенные объявления модулей). Если это проблема синтаксиса, все ужасно, и мы все равно сломаемся, поэтому подавления ничего не сделают (подавление не влияет на ошибки синтаксического анализа).

Спасибо за //@ts-nocheck , но это не решает проблему отключения проверки блока кода:

const $element = document.createElement('iframe')
$element.loading = 'lazy' // Property 'loading' does not exist on type 'HTMLIFrameElement'.

// @ts-nocheck

У меня есть интересный пример использования.

Мы создали или создали ORM на Typescript, который использует acorn для компиляции операторов в наш DDL.

Чтобы выполнить запрос where, мы должны передать ему переменные области видимости:

.entities
.include('parent')
.where(m => m.id === this.id, { id: this.entityId })
.toList()

Это не работает просто потому, что: Property 'id' does not exist on type 'xxx'

Если я оберну его в @ts-ignore-start , он будет нормально работать следующим образом:

// @ts-ignore-start
.where(m => m.id === this.id, { id: this.entityId })
// @ts-ignore-end

Но когда форматируется и начинает добавлять разрывы строк:

// @ts-ignore-start
.where(m => m.id === this.id || m.id === this.id2, {
  id: this.entityId,
  id2: this.entity2Id
})
// @ts-ignore-end

Это больше не работает.

Это не работает просто потому, что:

Это именно та ошибка на уровне типа, для которой вы должны просто иметь приведение as any (или, в jsdoc, /** <strong i="8">@type</strong> {any} */(expr) ) для доступа (ов), если вы действительно хотите ее подавить.

//@ts-nocheck не работает для моего проекта ts angular, но //@ts-ignore работает. Эта проблема для Microsoft началась в 2017 году. 2017! Вот это да...

Уже 3 года, а решения нет. Неудивительно, что разработчики JavaScript не хотят переходить на машинописный текст.

// @ts-ignore-start
// @ts-ignore-end

Можно комбинировать с: #19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

@marianturchyn это не tslint.

Есть планы реализовать это?

// @ts-nocheck
пока единственный вариант :(

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

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

В результате сгенерированный код может легко иметь недостижимый код или, в одном случае, TS2367, так как может быть вложенный код, который проверяет значение на соответствие константе перечисления, а затем внутри этого блока содержится еще одна проверка этой переменной на соответствие другой константе перечисления. Например:

if (foo === MyEnum.ONE) {
  const bar = (foo === MyEnum.TWO ? "two" : "one");
}

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

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

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

Ты серьезно? Это все еще открытая проблема и не реализована в TS4? 🤦🏽

@ivnnv Вы можете использовать // @ts-expect-error в TS 3.9, см. здесь

@ndraiman @ts-expect-error работает для отдельных строк, но не для блоков , поэтому по-прежнему необходимо размещать многие из них, если вы хотите «игнорировать блок».

Вот еще несколько отзывов для вас:

Что еще тебе нужно? Что должно сделать сообщество, чтобы получить эту функциональность?

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

У людей разные взгляды на то, что приемлемо, а что нет.

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

ПРИМЕР:

Один портирует проект с JS на TS, а другой проект разрабатывается сторонней организацией.

Синтаксис и правила, используемые в перенесенном проекте, могут быть либо старыми, например, es2015, либо устаревшими в пользу более четкого синтаксиса и меньшего количества кода и т. д.

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

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

Мой рабочий процесс, когда мне нужно портировать JavaScript на TypeScript (и код, ну, не на должном уровне):

1. Скопируйте код из файла .js в файл .ts.
2. Посмотрите, может ли TS вывести какие-либо типы по использованию
3. Вручную понять типы из использования
4. Осознайте, что ошибки - проклятие моего существования
5. Попробуйте закомментировать ошибки, тем самым улучшив количество строк в файле иногда х3 ESLlint + TS (чем больше, тем лучше?)
6. Удалите и добавьте // @ts-check вверху, тщательно отредактировав остальные файлы и добавив больше типов.

Если бы мы могли игнорировать блоки:

1. Скопируйте код из .js в .ts
2. Посмотрите, может ли TS вывести какие-либо типы по использованию
3. Вручную понять типы из использования
4. // @ts-ignore-enable ... // @ts-ignore-disable отдельные функции и проблемные кодовые блоки
5. Раскомментируйте блоки, когда я доберусь до них, и добавьте типы

Решайте сами, что кажется наиболее разумным. То же самое и при портировании JS в проект с большим количеством правил ESLint, и вам приходится рефакторить большинство вещей.

Я хотел бы сделать так, как это возможно в ESLint, и использовать /* eslint:disable */ ... /* eslint:enable */ в TypeScript.

PS Я только что понял, проверяя этот комментарий, что потратил более 20 минут, пытаясь получить опыт, который я (и многие другие) искали с 2017 года, просто чтобы прокомментировать открытую проблему, которой скоро исполнится 3 года.

@weswigham @RyanCavanaugh

Напоминание :+1:

Отдам первенца в обмен на это

@agusterodin Твоя жертва привлекает внимание зла.....

Ладно, на самом деле ничего не происходит, кроме того, что я просто даю простой пиар :)

Тем не менее, лично я полностью согласен с мнением команды TS - эта функция является злом, вы всегда должны стараться избегать использования @ts-ignore , не использовать @ts-ignore-enable (или @ts-ignore-start , что бы ни).
Но иногда, знаете, пословица говорит drinking posion to satisfie thirst , я знаю, что это плохой выбор, но он просто необходим.

изменить: добавить объяснение и примеры.
Этот PR добавляет две директивы ts-ignore-enable и ts-ignore-disable .

1. если использовать только ts-ignore-enable, все остальное игнорируется.

...   <-- this is normal
// @ts-ignore-enable
XXX    <-- this is ignored
...    <-- this is ignored

1. вы можете добавлять одни и те же директивы много раз, но они работают только один раз.

// @ts-ignore-enable
XXX  <-- this is ignored  
// @ts-ignore-enable       <-- you could remove this line.
YYY   <-- this is ignored
// @ts-ignore-disable
ZZZ   <-- this is normal
// @ts-ignore-disable      <-- you could remove this line.

1. // @ts-ignore-disable можно использовать отдельно, ничего не произойдет.

2. @ts-expect-error не будет работать в игнорируемом регионе

// @ts-ignore-enable
XXX  <-- this is ignored
// @ts-expect-error       <-- No error message. whatever next line has error or not.
YYY   <-- this is ignored

1. нет метки региона, это просто комментарий.

// @ts-ignore-enable A
XXX  <-- this is ignored  
// @ts-ignore-enable   B    <-- you could remove this line.
YYY   <-- this is ignored 
// @ts-ignore-disable B
ZZZ   <-- this is normal
// @ts-ignore-disable A     <-- you could remove this line.

В идеальном мире нам не нужно было бы игнорировать безопасность типов, верно? :пот_улыбка:
Мне это нужно при копировании фантастической работы, например, примеров и стартеров, даже случайного ответа SO, который не напечатан или не напечатан так, как я хотел бы. В основном, чтобы иметь его в моем безопасном коде, который соответствует моим настройкам. Я просто использую очень строгие настройки и из-за этого часто приходится переписывать функцию или какую-то логику. Это не потому, что я хочу игнорировать этот блок кода, это не имеет смысла.

Игнорирование блока кода — это удобство, которое мне кажется совершенно разумным, учитывая тот факт, что я все еще могу @ts-ignore каждую строку в блоке.

Я понимаю возможные последствия, которые это может иметь для людей, идущих I'll just ignore this because it's easier . Насколько я понимаю, любой, кто может использовать игнорирование области блока для drink poison to satisfy their thirst , уже пьет капли яда с @ts-ignore .

Теперь, когда вы можете делать @ts-nocheck в файлах .ts , я предлагаю также разрешить @ts-check в файлах .ts , чтобы мы могли отключить/включить проверку типов:

import fs from 'fs'

fs.readFileSync(32423) // type checking

// @ts-nocheck
fs.foobarbaz() // type checking is off
fs.__randomThing()

// @ts-check
fs.readFileSync(123) // now type checking again

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

ОБНОВЛЕНИЕ Я ошибся, см. https://github.com/microsoft/TypeScript/pull/40267#issuecomment -713840095 для исправления.

При попытке перенести приложение с помощью styled-components на TypeScript я столкнулся с проблемой, когда @ts-ignore нельзя использовать над строками шаблона (по какой-то причине). Это можно было бы решить с помощью блока игнорирования.

Пример ошибки TS, которую я пытался игнорировать:

import styled from "styled-components";
import { Button } from "...";

// @ts-ignore here does not work
const StyledNavBar = styled.div`
  ${Button} {
    margin: auto 0;
  }
`;

В качестве дополнительного примечания: я не могу использовать его в своем проекте TS, я не разрешаю никаких типов. Какая тогда рекомендация?

@weswigham Что вы думаете о состоянии потока и продуктивности в контексте эстетики? Кажется, вы не испытываете никакого сочувствия к кровоточащим глазам; но есть ли у вас какие-либо представления о производительности, переносе кода и процессах, которые я описал? Вы все еще не видите никакой выгоды _вообще_ после рассмотрения моего комментария и в контексте повышения производительности? Я также описал несколько реальных ситуаций, когда может потребоваться игнорирование области блока. Кроме того, как эта функциональность не сравнима с ESLint и той функциональностью, которую мы ожидаем от нее?

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

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

Команде нужно либо принять решение, либо реализовать явно желаемую функцию.

Держать вопрос в подвешенном состоянии не имеет никакого смысла.

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

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

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

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

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

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

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

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

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

Я привел несколько аргументов против точки зрения @weswigham , привел несколько примеров и, честно говоря, все еще жду какого-либо ответа на них. Единственное, что, казалось, помогало, так это быть явно расстроенным и неконструктивным.

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

Я хотел бы повторить, что я понимаю, что это не может быть высоким приоритетом, если мы отвлечем мнения людей от предмета. В то же время фича готова к реализации, аргументы приведены. Сейчас нужно, чтобы команда приняла решение/ответ (не обязательно реализовывать что-либо) и обнародовала его. Если это не то, что требуется, то, пожалуйста, скажите мне, что, или как можно было бы повысить приоритет _любой_ функции или проблемы для TypeScript, но особенно этой.

Другой вариант использования многострочного ( @ts-ignore-start+@ts-ignore-end ) или встроенного (например, /* @ts-ignore */ ) @ts-ignore .
Окружающая обстановка:

• "noUnusedParameters": true
• Включено правило ESLint require-jsdoc .
• Код, аналогичный следующему (упрощенный пример):

type Data = Record<string, unknown>;
type PrepareSettings = Record<string, unknown>;

/**
 * This is base class that will be inherited.
 */
class SuperClass {
    /**
     * Prepare data for further usage.
     * 
     * <strong i="16">@param</strong> data
     *      Data that should be prepared.
     * <strong i="17">@param</strong> settings
     *      Operation settings.
     */
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {
        return data;
    }

    // Some additional methods...
}

Для описанной ситуации TypeScript выдает следующее предупреждение: 'settings' is declared but its value is never read.(6133) .
Предупреждение можно отключить, добавив @ts-ignore после конца комментария к документации:

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {

Но после этого ESLint будет жаловаться на Missing JSDoc comment .
Итак, решение:

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {   // eslint-disable-line require-jsdoc

Что некрасиво и некрасиво.

@RyanCavanaugh @weswigham @sandersn

Ежемесячное напоминание о том, что сообщество хочет обсудить это с командой TypeScript. Есть большая поддержка, и чего в настоящее время не хватает, так это ответа от команды. Я понимаю, что есть много предположений, и развитие TypeScript — нелегкий подвиг. Дела требуют времени. Поскольку нет ответа относительно того, как мы можем продвинуть это предложение и предпринять более прямые действия, я буду регулярно напоминать об этом. Я не сдамся, пока решение не будет принято, и комментарии, кажется, влияют (в основном, когда я !@#).

По прошествии этих лет, хотя я изначально был ошарашен тем, что этого функционала там нет, я лично немного переосмыслил его... Когда есть огромная куча @ts-ignore , вы уже можете сказать, что что-то не так с вашим кодом и потратьте некоторое время на улучшение ваших типов. Мы все иногда довольно ленивы и хотим скорости в целом, но в настоящее время часто проще определить несколько правильных типов, чем копировать и вставлять несколько @ts-ignore в большие куски кода. Если этот баланс НЕудобства будет нарушен, многие из нас будут удобно злоупотреблять @ts-ignore-enable, что может только снизить общее качество всех небольших проектов с открытым исходным кодом здесь и там.

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

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

Либо удалите функциональность @ts-ignore , либо сделайте ее полноценной. Есть много аргументов в пользу этого, и люди, пишущие плохой код, будут продолжать использовать @ts-ignore , что так же плохо, как функция игнорирования блоков, это то же самое, за исключением того, что игнорирование блоков менее визуально разрушительно.

Сообществу все еще нужен ответ от команды TypeScript.

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

Либо удалите функциональность @ts-ignore , либо сделайте ее полноценной. Есть много аргументов в пользу этого, и люди, пишущие плохой код, будут продолжать использовать @ts-ignore , что так же плохо, как функция игнорирования блоков, это то же самое, за исключением того, что игнорирование блоков менее визуально разрушительно.

Сообществу все еще нужен ответ от команды TypeScript.

В некоторых особых сценариях по-прежнему необходимо использовать игнор @TS. Например, импорт CDN не зависит от node_ The. Файл TS не существует в сценарии модулей

@ L-Hknu Спасибо за разъяснение. Люди используют его так же, как игнорирование с ESLint.

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

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

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

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

@ L-Hknu Спасибо за разъяснение. Люди используют его так же, как игнорирование с ESLint.

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

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

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

Похоже, это сделано
№40267