И это печаль

А при сборке через npm:package он просто добавляет декларации с подмодулями собирая их в один файл в typings

Что в IDE задублирует определения

тайпингс уже почти не нужен

Кстати, есть свежак по этой теме?

тайпингс уже почти не нужен

почти тут ключевое слово

есть бета 2.0

npm пока что не спасет

половина пакетов побитые до сих пор, issue все еще висят в их автопаблишере

npm:package ставит из локальной копии

в этом отличие от npm~package

есть бета 2.0

Может я там не разобрался до конца, но вообще стоит.

а, и там вроде еще репаблиш не запилили

короче все сложна

https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/

https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/

там еще много проблем, да

там еще много проблем, да

ну по факту использовать даже на этапе разработки не получится

костылями не подопрешь, там банально битые пакеты лежат

например history без папки lib

ну там вроде много таких пакетов

я и не говорил же что тайпингс не нужен)

именно поэтому

ага, я начинаю понимать, как тебя понимать)

Всем declare module "*"; ребята :)

почему тайпскрипт проше джс?

в понимании?

Мой коллега(джава, C++) после того, как увидел примеры кода на ts, кажется vscode, сказал, что читать такой код проще, он сам себя описывает, сам документирует за счёт типов. Как-то так.

Мой коллега(джава, C++) после того, как увидел примеры кода на ts, кажется vscode, сказал, что читать такой код проще, он сам себя описывает, сам документирует за счёт типов. Как-то так.

У Java разве не также?

в понимании?

потому что костылей меньше

почему тайпскрипт проше джс?

в js основной принцип до es6 это "ебитесь как хотите", ts дает чуть больше стандартных вещей. Это не значит, что на ts код будет лучше или что-то в этом духе, но новичкам стрелять себе в ногу чуть сложнее

Всем declare module "*"; ребята :)

ха)

У Java разве не также?

в сравнении с js была речь.

но в тоже время, нельзя сказать, что ts так уж много добавляет в js, не так уж меньше становится способов стрелять в ногу

обмазаться декораторами по самое уши

@luanre кажется TS 2.0 и @types решает твою проблему.

Глобальные зависимости поставятся из @types, которые у тебя будут в dependencies твоих приватных модулей.

Мне тоже так кажется, но в нашей версии nexus нет поддержки scoped packages

Я сейчас библиотеку обновил и понял, что теперь же у нас все полноценно работает с репой типов, ставятся зависимости как и должно. @types/node само подцепилось. Правда я так думаю, могут возникнуть проблемы с версиями.

Вот и думаю над костылями

Обновить версию? Я недавно поставил последнюю версию, ушло полчаса времени.

Нет там миграции никакой?

В крупном enterprise все очень медленно)

Понятно)

Пока единственное решение, которое я придумал - это запатчить typings

Но боль никуда не денется)

но в тоже время, нельзя сказать, что ts так уж много добавляет в js, не так уж меньше становится способов стрелять в ногу

Немного, но то, что очень сильно требуется с точки зрения джавистов, например. Недавно просто как раз объяснял современный фронтенд другу, он typescript воспринимал со слезами счастья на глазах)) Объявление типов, дженерики, enum,чуть более вменяемый синтаксис классов, вот это всё

ну знакомые и не сильно нужные protected, ага)

Кстати насчет enum, есть какая то либа чтобы сделать их получше?

Ну если сделать вот так: typings install смотрит зависимости в package.json, находит зависимости с указанным полем typings, ищет в корне typings.json и сливает зависимости оттуда. Мне кажется, должно сработать

А чем enum не нравится?

Кстати насчет enum, есть какая то либа чтобы сделать их получше?

Мне очень нравится enumify http://www.2ality.com/2016/01/enumify.html

А чем enum не нравится?

Банально нет values чтоб перебрать все значения

Имхо, для этого лучше использовать объекты

Ну если сделать вот так: typings install смотрит зависимости в package.json, находит зависимости с указанным полем typings, ищет в корне typings.json и сливает зависимости оттуда. Мне кажется, должно сработать

Не очень понимаю, почему этого не сделали изначально.

Мне очень нравится enumify http://www.2ality.com/2016/01/enumify.html

Норм. Еще понравилась идея использовать символы для значений enum

Мб свой велосипед сделать

Мб свой велосипед сделать

Я как-то начинал свой велосипед на символах)) Потом наткнулся на эту либу и решил не переизобретать написанное

Я как-то начинал свой велосипед на символах)) Потом наткнулся на эту либу и решил не переизобретать написанное

Но там в итоге экземляры класса используются а не символы, немного тяжеловесно

Банально нет values чтоб перебрать все значения

а зачем?

а зачем?

Ну у меня например enum это слой в рендере, нужно перебрать все слои поочередно

О.о

может enum не для этого?))

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

может enum не для этого?))

А что тогда использовать

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

а она их все одинаково обрабатывает?

а она их все одинаково обрабатывает?

Не важно

А что тогда использовать

я не понял кейс, честно говоря этот

Не важно

так если по-разному, то надо и разные кейсы описывать

А что тогда использовать

es6 Set, например?

При чем тут сет?

я не понял кейс, честно говоря этот

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

в enum храните метку определения слоя, в каком-то списке храните порядок вывода

в enum храните метку определения слоя, в каком-то списке храните порядок вывода

enum поменялся - не забыть этот список поменять нужно

конечно, ведь enum не просто так поменялся

а в каком порядке вы будете перебирать важно ж наверное для enum

если даже он отдавал бы values, то в каком порядке?

конечно, ведь enum не просто так поменялся

А удобно бы было, если бы можно было у enum получить список значений?

да вроде нет

если даже он отдавал бы values, то в каком порядке?

В порядке в котором значения определены

с чего это вдруг

Это не гарантируется, вроде бы

Ну, бро, по реализации так. Enum в ts начинается с 0 и идет по возрастанию

Это не гарантируется, вроде бы

В библиотеке которую ты кинул?

В общем я сейчас делаю так - кроме enum еще экспортируется специальный объект класса унаследованного от enumdetails<T> где есть values и нужные кастомные методы. Сам список значений выковыривается из нативного enum через рефлексию

В библиотеке которую ты кинул?

В стандартном enum, если

*если это не enum const

В стандартном естественно нет такого, если перебирать for..in еще и цифровые и символьные значения будут

Тебе сейчас проще всего взять эту либу и сделать лист Enum`ов с функциями внутри. Не перебор через values 100%. В общем суть в том, что лучше не возлагать такую вещь, как порядок на тонкости реализации. Короче дело твоё, но что-то смутно тут не нравится, мне кажется, что мы тут сейчас Set/Map с сортировкой изобретаем))

Я бы вообще сделал массив функторов и не парился)

Тебе сейчас проще всего взять эту либу и сделать лист Enum`ов с функциями внутри. Не перебор через values 100%. В общем суть в том, что лучше не возлагать такую вещь, как порядок на тонкости реализации. Короче дело твоё, но что-то смутно тут не нравится, мне кажется, что мы тут сейчас Set/Map с сортировкой изобретаем))

Очевидно они сортируются по значению, и я даже вручную задаю значение у каждого элемента енама

Так что все норм, спс

Я думал есть что то общепринятое

Я бы вообще сделал массив функторов и не парился)

Эмм, поясни

Эмм, поясни

Ну это если вместо ООП функциональное программирование использовать)) (условно) : printLayer=(layer)=>print(layer) bottom = printLayer(getBottom) ... images.forEach(img=>img.printLayers([bottom,middle,top])) Ну то есть абстрагируясь, в любом случае должна быть функция для печати слоя; вызывая её с нужными параметрами, делаем функции для печати конкретных слоёв, тогда можно просто сохранить их как массив и вызывать перебором, и изображение заведомо будет обрабатываться в нужном порядке

Ну я у тебя все равно явный список слоев вижу

Ну и я просто на слово функтор среагировал, не понял что ты имел в виду функцию

Ну я у тебя все равно явный список слоев вижу

Он у тебя есть изначально по условию, только тут это не отдельный enum а тупо список универсальных функций-геттеров каждого слоя в любом удобном тебе порядке. Фишка в том, что они инкапсулируют всю реализацию твоих слоёв. Отслюда уже один шаг до энумов, считай это и есть enum, только без побочных эффектов)) Функтор - это функция, которая принимает на вход другую функцию Ладно, тут в любом случае не на пару постов тема?

Он у тебя есть изначально по условию, только тут это не отдельный enum а тупо список универсальных функций-геттеров каждого слоя в любом удобном тебе порядке. Фишка в том, что они инкапсулируют всю реализацию твоих слоёв. Отслюда уже один шаг до энумов, считай это и есть enum, только без побочных эффектов)) Функтор - это функция, которая принимает на вход другую функцию Ладно, тут в любом случае не на пару постов тема?

Это функция высшего порядка, а не функтор

Он у тебя есть изначально по условию, только тут это не отдельный enum а тупо список универсальных функций-геттеров каждого слоя в любом удобном тебе порядке. Фишка в том, что они инкапсулируют всю реализацию твоих слоёв. Отслюда уже один шаг до энумов, считай это и есть enum, только без побочных эффектов)) Функтор - это функция, которая принимает на вход другую функцию Ладно, тут в любом случае не на пару постов тема?

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