а, я на разные сообщения ответил. это богдан написал про float-double. ну вот а 10.0-3.45 в контексте чисто дабла выдаст фигню с погрешностью. я тут и не спорю

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

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

так и живем

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

12.12345 не представимо в double

та память, которую дает литерал 12.12345f имеет четкий аналог в дабле

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

А это нормально, что binaries.library игнорит webpackTask.outputFileName?

Коллеги, а никто не разбирался часом с конфигурацией таска :kotlinNpmInstall ? Такое впечатление, что на CI сервере он каждый раз выкачивает все npm зависимости заново. Куда он их, интересно, складывает? Кэширование GRADLE_USER_HOME (который смотрит на .gradle собираемого проекта) включено, но что-то не помогает, похоже.
Какие-то node_modules найдены в build/js но кэширование чего-то из build на CI сервере выглядит дикой идеей.

в build корневого проекта

Воооот там они и лежат(node_modules), да

А разве другие кеши при сборке гредловых проектов не в buildDir проектов складываются?

Сейчас для kotlinNpmInstall таски кэширование настроить проблематично
В основном причина - то, что тогда все node_modules надо отмечать как output directory, и это очень сильно увеличивает время этой таски (соответственно чем толще эта папка, тем больше время)
При этом время, которое в kotlinNpmInstall тратится в том числе тратится на файловые операции создания структуры node_modules
В этом плане, копирование из кэша тоже не будет моментальным (хотя на network операциях экономия конечно будет)

Ну по крайней мере "мавеновские" зависимости каждый раз заново не скачиваются

А, в разрезе зависимостей отчасти согласен. Хотя тут вопросы к npm, в том мире зависимости всегда per project были.

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

Не быстрее ли будет скачать )

Ну то есть это наверное ж можно оптимизировать, но придётся воевать с платформой :)

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