Локально у разработчкика все работает, а другие члены команды этот модуль не видят.
Человек всегда слабое звено, любую систему можно поломать человеческой глупостью и отстствием ответственности. Кто на прописал все зависимости в package.json тому по рогам настучасть тк не понимает воркфлоу.
--cache-min Infinity не решает проблему, это большой костыль. Я тоже так начинал, но в итоге пришлось использовать сторонние тулзы для кешрования, я их кучу перепробывал — остановился на https://github.com/swarajban/npm-cache (интегрировал в Maven сборку).
А я сталкивался и не один раз. Но самом деле можно делать оверрайд зависимостей второго порядка (неявных) и также фиксировать версии — Shrinkwrap, но это неудобно очень (конфиг файл большой). Я делаю немного по другому (кешрую весь каталог nmp_moules, для этого есть готовые тулзы всякие) ну и всегда указываю версии явно без всяких ~^ и тд.
Беспокоится не о чем, несолько дополнительных скоупов на скорость ресолвинга var переменной не особенно повлияют (hoisting). О скорости следует думать в более глабольшом машстабе, на этапе дизайна системы и имплементации логики.
Верно, зачем мне себя ограничивать и пользоваться поиском на каком-то одном конкретно ресурсе если гугл ищет сразу по всем ресурсам интернета и прекрасно выдает ссылки в том числе и на стековерфлоу.
Может я что-то и подтвердил, хз. База знаний на основе стековерфлоу очевидно мне без особой надобности, я лучше просто спрошу гугла и он ответит, главное правильно спросить.
V8 / Chakra и тп вторичные вещи по моему мнение. Для большой кодовой базы, большой команды, и написания бизнес логики важны более общие вещи, например строгая типизация, поэтому я за вариант — перспектива появится когда использование чистого JS станет "плохой практикой" (по крайней мере на бэкенде), а обычным делом будет все писать на TypeScript (или чем-то похожем к тому времени).
до сих пор прячут неявную магию по которой вычисляется как находить перестановку элементов
В реакте сложные механизмы и тоже бывали баги с перестановкой. Я бы сказал ценность виртуального DOM переоценена, по мне так он в большинстве случаев вообще не нужен. Но если его удалить, то что тогда останется от этого риакта :)
PS благодарю за линку, я как раз планировал присмотреться к этой поделке, но скорее всего сфокусируюсь на втором ангуляре тк его делают инженеры, а не хипстерня всякая.
Ок, но я все же как нибудь посмотрю тоже в код. Я выше не призывал использовать эту поделку, но указывал что не считаю риакт какой-то уникальной серебрянной пулей.
Также у Реакта наиболее "дешевое", с точки зрения производительности, дробление на компоненты — каждый компонент — это функция (либо класс), а в Ангуляре, например, это дополнительная куча watcher-ов.
Потому что реакт не тракает именения, он просто рисует то что ему сказали рисовать. Это не ферймворк, а просто библиоетка перерисовки DOM с некоторыми элементами оптимизации (некоторые скажут с хаками и манки патчингом), считай продвинутый теймпейлетер. То есть ты сам должен ему сказать когда перересовывать.
Как по мне риакт далеко не уникален, и это просто хайп вокрг него и ничего более. Кроме того он слишком усложняет дело со своим вирруальным DOM деревом, вычисляя что именно патчить в реальном дереве. Я бы лучше посмотрел в сторону Riot JS.
Человек всегда слабое звено, любую систему можно поломать человеческой глупостью и отстствием ответственности. Кто на прописал все зависимости в package.json тому по рогам настучасть тк не понимает воркфлоу.
npm ничего не тормазит присборке CI, просто кто-то не умеет (не хочет, не видит необходимости) кешровать модули грамотно.
--cache-min Infinity не решает проблему, это большой костыль. Я тоже так начинал, но в итоге пришлось использовать сторонние тулзы для кешрования, я их кучу перепробывал — остановился на https://github.com/swarajban/npm-cache (интегрировал в Maven сборку).
А кешировать при билде что не позволяет? Для этого есть множество готовых тулов.
А я сталкивался и не один раз. Но самом деле можно делать оверрайд зависимостей второго порядка (неявных) и также фиксировать версии — Shrinkwrap, но это неудобно очень (конфиг файл большой). Я делаю немного по другому (кешрую весь каталог nmp_moules, для этого есть готовые тулзы всякие) ну и всегда указываю версии явно без всяких ~^ и тд.
Беспокоится не о чем, несолько дополнительных скоупов на скорость ресолвинга var переменной не особенно повлияют (hoisting). О скорости следует думать в более глабольшом машстабе, на этапе дизайна системы и имплементации логики.
очевидно в es5 let/const транслируется в var всегда
Верно, зачем мне себя ограничивать и пользоваться поиском на каком-то одном конкретно ресурсе если гугл ищет сразу по всем ресурсам интернета и прекрасно выдает ссылки в том числе и на стековерфлоу.
Может я что-то и подтвердил, хз. База знаний на основе стековерфлоу очевидно мне без особой надобности, я лучше просто спрошу гугла и он ответит, главное правильно спросить.
V8 / Chakra и тп вторичные вещи по моему мнение. Для большой кодовой базы, большой команды, и написания бизнес логики важны более общие вещи, например строгая типизация, поэтому я за вариант — перспектива появится когда использование чистого JS станет "плохой практикой" (по крайней мере на бэкенде), а обычным делом будет все писать на TypeScript (или чем-то похожем к тому времени).
Я просто не вижу смысла задвать вопрос и ждать ответа, проще самому найти ответ, обычно ответ нужен "сейчас", а не когда тебе его кто-то выдаст.
Я не знаю что творится на тостере, впрочем как и на стековерфлоу, и прекрасно обхожусь без этого знания.
Ни разу не отвечал там и даже не возникало желания. Ответы находил бывало, время экономило, а если не находил там, то находил сам.
https://habrahabr.ru/company/oleg-bunin/blog/311096/
Еси не хипстерить, то вероятно таким инструментом вскоре станет второй ангуляр, но разумеется только для серьезных проектов.
Вот вот, от риакта осталось одно название.
В реакте сложные механизмы и тоже бывали баги с перестановкой. Я бы сказал ценность виртуального DOM переоценена, по мне так он в большинстве случаев вообще не нужен. Но если его удалить, то что тогда останется от этого риакта :)
PS благодарю за линку, я как раз планировал присмотреться к этой поделке, но скорее всего сфокусируюсь на втором ангуляре тк его делают инженеры, а не хипстерня всякая.
Ок, но я все же как нибудь посмотрю тоже в код. Я выше не призывал использовать эту поделку, но указывал что не считаю риакт какой-то уникальной серебрянной пулей.
Я в код не смотрел, но обычно баг имплементации не указывает на баг инструмента.
Потому что реакт не тракает именения, он просто рисует то что ему сказали рисовать. Это не ферймворк, а просто библиоетка перерисовки DOM с некоторыми элементами оптимизации (некоторые скажут с хаками и манки патчингом), считай продвинутый теймпейлетер. То есть ты сам должен ему сказать когда перересовывать.
Как по мне риакт далеко не уникален, и это просто хайп вокрг него и ничего более. Кроме того он слишком усложняет дело со своим вирруальным DOM деревом, вычисляя что именно патчить в реальном дереве. Я бы лучше посмотрел в сторону Riot JS.