Rollup-plugin-typescript2: Параметр tsconfig по умолчанию "include" переопределяется индексом из исходного tsconfig.json.

это делает невозможным использование include поскольку вы никогда не знаете, как долго массив будет находиться в tsconfig.json

Интересная штука,
если я перемещаю параметр typescript2 config include с tsconfigDefaults на tsconfigOverride
он заменит исходную опцию tsconfig.json include по индексу.

то есть это с точностью до наоборот
но это тоже очень плохо

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

Итак, я уже сталкивался с этой проблемой в https://github.com/jaredpalmer/tsdx/pull/666#discussion_r404847759 , и по этой проблеме именно так работает глубокое слияние _.merge . Это глубокое слияние, поэтому оно объединяет массивы, и индекс является единственным идентификатором массива. Это может быть неожиданно, но это глубокое слияние, вот как работают глубокие слияния.

Фактически, он не объединяет эти свойства, а заменяет значения в индексной ячейке ,

• Вместо этого выполнение append / concat вообще не будет объединять и вообще не даст возможности перезаписать с помощью tsconfig . Мне это кажется неправильным поведением.
• Вместо этого выполнение неглубокого слияния просто перезапишет то, что по умолчанию, что, я не уверен, является ожидаемым поведением, но это похоже на то, как tsconfig работает в отношении exclude : если вы добавите exclude , он перезаписывает значения по умолчанию.

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

если я перемещаю параметр typescript2 config include с tsconfigDefaults на tsconfigOverride
он заменит исходную опцию tsconfig.json include по индексу.

то есть это с точностью до наоборот

Да, именно так должен работать tsconfigOverride , это переопределение.

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

Да, именно так _.merge выполняет глубокое слияние, поэтому все в tsconfig , являющееся массивом, имеет такое же изменение.

@ agilgur5 спасибо за ответ!

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

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

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

Мое предложение:
1) по умолчанию - собрать свойство по умолчанию и объединить с исходным tsconfig; удалить дубликаты.
2) для переопределения - применить только опцию переопределения

Значения по умолчанию обычно не объединяются при переопределении, они переопределяются. И, как я упоминал выше, конкатенация делает невозможным_ переопределение значения по умолчанию с помощью tsconfig . Во многих отношениях это звучит для меня как неправильное поведение, поэтому я категорически против этого.

Я думаю, что все варианты сбивают с толку, я не уверен, что согласен с тем, что любой из них является «лучшим DX». Неглубокое слияние - это наиболее близкая вещь к тому, как tsconfig работает со своим значением по умолчанию exclude , но это не обходится без компромиссов.
В общем, критические изменения требуют много обдумывания, поэтому я поднял этот вопрос - последующие эффекты нетривиальны; TSDX также должен будет выпустить критическое изменение, чтобы обновить его.

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

Дело:

1. Я хочу добавить дополнительные символы d.ts в свойство конфигурации "include".
2. Пользователь помещает свою директорию src внутрь "include" с другими типами d.ts за пределами src другого проекта.

1. ['config.d.ts`]
   2. ['src', 'some.d.ts', 'another.d.ts']
2. Результат: ['src', 'some.d.ts', 'another.d.ts']

Как видите, правильно настроить это невозможно. Я должен прочитать tsconfig.json, получить его свойство "include" и объединить его с ['src', 'some.d.ts', 'another.d.ts', 'config.d.ts'].
И я считаю, что это сплошные накладные расходы.

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

Я так вижу, что если оставить все как есть, то я не смогу его использовать, это черный ящик для меня, потому что я ничего не могу гарантировать.
Здесь нет места личным предпочтениям «нравится» / «не нравится».
Это можно либо использовать, либо нет. А это невозможно.

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

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

Опять же, «значение по умолчанию», которое нельзя изменить, не является значением по умолчанию, это требование. Изменение «по умолчанию» на требование не имеет смысла и является неправильным поведением.

Вы можете отменить глубокое слияние прямо сейчас, вы не можете отменить конкатенацию. Делать существующий вариант использования невозможным не имеет смысла.

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

Я внес здесь свой вклад, чтобы исправить ошибки раньше (я знаю, что это _.merge потому что я читал кодовую базу), и поддерживаемая мной библиотека составляет значительную часть использования этой библиотеки (~ 10%), я здесь не просто тезисы для разговора ...

Не говоря уже о том, что эту проблему можно решить без нарушения изменений - вы можете добавить новую опцию для tsconfigConcat или tsconfigDefaultShallow и т. Д.

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

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

• tsconfigDefaults - это объект, в который все ниже будет глубоко объединено
• tsconfig - это объект, который мы получаем из машинописного текста после его собственного импорта и всего остального. Все значения здесь заменяют значения в tsconfigDefaults . Все массивы здесь объединены с массивами в tsconfigDefaults .
• tsconfigOverride - это ядерный вариант. Объекты по-прежнему глубоко объединяются, но массивы здесь полностью заменяют массивы. Поэтому, если вы укажете здесь пустой включаемый массив, в окончательном tsconfig вообще не будет включений.

Будет ли это охватывать все случаи, которые мы хотим поддержать (после того, как пользователи внесут соответствующие изменения), или мне что-то не хватает?

@ezolenko звучит потрясающе и имеет большой смысл в использовании

@ezolenko Я не уверен, зачем тебе ломать вещи? Я уже привел варианты, которые не ломаются.

Я не уверен, как то, что вы перечислили, отражает «дух документации и имен свойств», потому что в документации говорится:

Объект, переданный как tsconfigDefaults будет объединен с загруженным tsconfig.json . Окончательная конфигурация, переданная в машинописный текст, будет результатом того, что значения в tsconfigDefaults заменены значениями в загруженном tsconfig.json
[...]
Это глубокое слияние (объекты объединяются , массивы объединяются, примитивы заменяются и т. Д.), Увеличьте verbosity до 3 и ищите parsed tsconfig если вы получите что-то неожиданное.

В нем написано «объединено», «заменено» и «глубокое слияние», что означает замену и переопределение значения по умолчанию. Есть единственная ссылка на «конкатенированный», которая _отличается от остальных_, но глубокое слияние фактически _не_ конкатенации. 5 ссылок говорят об одном, а 6 - неверно. На мой взгляд, это звучит так, как будто шестая ссылка, которая является неправильной, должна быть исправлена, а не 5 правильных ссылок на неправильную шестую.

lodash является стандартом де-факто, и его определение слияния _не_ объединять. Определение значений по умолчанию состоит в том, что они переопределяются, когда вы устанавливаете одно и то же значение свойства, _не_ конкатенировано:

_.defaults({ a: ['a'] }, { a: ['b', 'c'] });
// => {a: ['a']}
_.defaultsDeep({ a: ['a'] }, { a: ['b', 'c'] });
// => {a: ['a', 'c']}

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

Он также нарушает симметрию с tsconfigOverride и собственными документами:

• tsconfigOverride : {}
  См. tsconfigDefaults .

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

Как я уже сказал, неглубокое слияние массивов может быть более интуитивно понятным, поскольку именно так на самом деле работает tsconfig _itself_. Как я уже писал выше, tsconfig _itself_ не объединяется, когда вы добавляете exclude , он переопределяет существующий exclude .

Таким образом, concatenate не соответствует 5+ ссылкам в документации, определению слияния, определению значений по умолчанию и собственному поведению tsconfig . И это нарушает симметрию и документацию других вариантов. Я не уверен, насколько это интуитивно понятно.

И, как я уже говорил несколько раз, создание очень неинтуитивной конкатенации вместо переопределения делает определенные варианты использования _ невозможными_ . Вот использование TSDX:

https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

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

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

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

@ agilgur5

И, как я уже говорил несколько раз, превращая его в очень неинтуитивную конкатенацию вместо переопределения
делает некоторые варианты использования невозможными. Вот использование TSDX:
https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

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

Самое смешное, что мы с

Значения по умолчанию применяются только в том случае, если вы не указали имя свойства.

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

для них невозможно переопределить значение по умолчанию

Вопрос в том, почему у пользователя должен быть доступ к тому, что автор библиотеки запретил?

Мы должны использовать конфигурацию tsconfig, которую нельзя перезаписать, но в то же время нам нужно дать возможность расширить наши предустановки. И это главное.

Решение заключается только в дизайне нового API.

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

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

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

Вопрос в том, почему у пользователя должен быть доступ к тому, что автор библиотеки запретил?

tsconfig не запрещал этого, TSDX не запрещал этого, и rollup-plugin-typescript2 не запрещал и этого, поэтому я не знаю, о чем вы говорите.

Мы должны использовать конфигурацию tsconfig, которую нельзя перезаписать, но в то же время нам нужно дать возможность расширить наши предустановки. И это главное.

Решение заключается только в дизайне нового API.

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

tsconfigConcat решит ваш вариант использования и более интуитивно понятен, потому что он буквально имеет concat в имени, и это именно то, что он делает.
Изменение tsconfigDefaults на "конкатенацию" не потому, что это в пятый раз _не то, что означает_ по умолчанию_.

по умолчанию = \ = конкатенация. Это не мое мнение, это определение.

@ agilgur5 извини, но тебя нельзя воспринимать всерьез.
каждый твой приговор спорен, я устал от него.

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

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

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

Я думаю, что у меня создалось впечатление, что слияние lodash на самом деле объединяет массивы (чередование их или что-то в этом роде), когда я писал эту часть. Или я даже не обращал внимания на то, что происходит с массивами. Поскольку он, по-видимому, перезаписывает содержимое массивов, используя индексы в качестве имен элементов (верно? Это javascript-то, что массивы изначально не были настоящими массивами, а вместо этого были словарями, у которых были числа для ключей?), Наша документация на данный момент лежит.

В идеале параметры tsconfigs по умолчанию / main / override должны позволять настраивать все параметры, как скалярные значения, так и массивы, одним и тем же неудивительным образом. Lodash-способ замены элементов массива на основе индекса имеет один существенный недостаток - вы не можете создавать буквальные разреженные массивы (возможно, заполнение массива кучей undefined s?). Это означает, что конфигурация накопительного пакета должна создаваться динамически, а tsconfig, будучи файлом json, не может их выполнять вообще.

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

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

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

Изменение обоих слияний для замены массивов оптом, как предлагается @ agilgur5, вероятно, наименее удивительный вариант, он позволит удалить значения за счет необходимости повторять значения, которые нужно сохранить. Однако это все еще критическое изменение, и для этого людям придется переписывать свои конфигурации (см. Https://xkcd.com/1172/).

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

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

@ezolenko я вижу следующий путь

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

Что это говорит нам? Начнем с семантики:

Как я сказал ранее

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

Мы можем полностью переделать эту вещь.

Мои предложения:

1. Примените свойства tsconfigDefaults если исходный tsconfig не имеет соответствующих свойств.
2. tsconfigOverride должен позаботиться об этом.
   2.1 Он должен работать, как и раньше, со скалярными значениями.
   2.2 Он должен объединять свойства массива. (вероятно, это ничего не должно сломать и должно соответствовать мотивации конфигурации)

Я просто пытаюсь избежать третьего дополнительного варианта rpt2, потому что он усложнит этот API как минимум на 50%, и любой разработчик перестанет это понимать.

@ agilgur5 Замечательно, что реальность и слова, которые вы говорите, не одно и то же.

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

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

@maktarsis, как в вашем подходе разработчик сможет удалять или исключать записи из tsconfig? Сценарий таков: у вас есть tsconfig.json, который используется где-то еще, вы хотите использовать его в свертке, не касаясь самого json, но по какой-то причине вы хотите удалить строку из массива excludes.

@ezolenko я хоть понял твою.

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

Я до сих пор не вижу ситуаций, когда нужно переписать исключение.
Тем не менее, я считаю, что нам не нужно перезаписывать "exclude" разработчика. Другими словами, я не могу представить, почему.
Необходимо понять причину «почему-то».

Если вы хотите иметь такую ​​возможность в любом случае, вам необходимо предоставить дополнительный API для конкатенации.
Но, как вы понимаете, я думаю, что он может быть невостребованным и просто ненужным.
Исключение чего-либо из "exclude" может и не быть необходимым, но если мы пойдем другим путем, то усложним понимание конфигурации.

Нам нужно и то, и другое: добавление чего-то в массив, которого нет, и удаление чего-то из него. При мелком слиянии и добавление, и удаление выполняются путем репликации всего массива (с изменениями) на более высоком уровне. Не очень удобно, но практично.

То же самое и с "esModuleInterop": true которого моя библиотека не работает в некоторых средах.

Бесполезная опция компилятора в config.json:

{
   ...
  "compilerOptions": {
       ...
      "esModuleInterop": true,
  },
}

Полезная опция компилятора в rollup-config:

typescript({
    useTsconfigDeclarationDir: true,
    tsconfigOverride: {
      esModuleInterop: true,
    },
  }),

Первое предложение @maktarsis было для меня ожидаемым поведением:

Примените свойства tsconfigDefaults, если исходный tsconfig не имеет соответствующих свойств.

^ комментарий выше не имеет отношения, поскольку он не для include или массивов. Упомянутое "предложение" - это то, что tsconfigDefaults уже делает.
Также я и TSDX часто использую esModuleInterop поэтому я знаю, что он работает в tsconfig.json , не уверен, что этот комментарий должен означать. В опубликованной конфигурации также отсутствует compilerOptions , это должно быть:

js typescript({ useTsconfigDeclarationDir: true, tsconfigOverride: { compilerOptions: { esModuleInterop: true, }, }, }),

Но это переопределит и сработает так, как задумано.

Отмечая здесь, что неглубокое слияние ранее упоминалось в этом репо несколько раз: # 86 (в котором упоминается неглубокое слияние TS, как я здесь), https://github.com/ezolenko/rollup-plugin-typescript2/issues/72 #issuecomment -383242460 и https://github.com/ezolenko/rollup-plugin-typescript2/issues/208#issuecomment -594237841.