Open Guria opened 9 years ago
bemjson для тестов
{
"block": "kg-appbar",
"content": [{
"elem": "panel",
"content": [{
"elem": "logo",
"content": {
"block": "logo",
"mods": {},
"content": [{"block": "logo", "elem": "img", "mods": {}}, {"tag": "span", "content": "Сотрудник"}]
}
}, {"elem": "app-title"}, {"elem": "controls", "content": [{"block": "user", "mods": {}}]}]
}, {"elem": "progressbar", "mods": {"indeterminate": true}}, [{}]]
}
Воспроизводится на последнем project-stub https://github.com/Guria/project-stub/tree/bemhtml-bug
@Guria предположу, что такое поведение появилось не после перехода на новую версию bem-core, а после перехода на мажорную версию enb-bemxjst
?
Там среди прочих изменений новая версия bem-xjst
, которая научилась рекурсивно выполнять applyNext
/applyCtx
. Поэтому, для случая, когда необходимо завернуть текущий контекст, следует использовать wrap()
: https://github.com/bem/project-stub/commit/3b17073a1ef4980de908f75d767d4283b75df323
@tadatuta в данный момент изменилась только версия bem-components и bem-core. npm зависимости и конфиг enb не менялись. Откат до 2.6.0 устраняет проблему. enb-bemxjst v1.3.5
Да, это я ошибся. Изменение посчитали исправлением бага: https://ru.bem.info/libs/bem-core/v2.7.0/changelog/#В-релиз-вошли-следующие-исправления-ошибок («Исправлена ошибка в i-bem.bemhtml, из-за которой неверно интерпретировались вложенные вызовы applyNext (b1dc50c).»).
В референс про wrap()
добавим, завел задачу. Спасибо!
@tadatuta мне кажется или это тянет на мажорный апдейт по семвер?
Кстати ещё для @sbmaxx задачка - обновить bem-core в песочнице
@Guria наверное да, но поздно пить боржоми :( Изменение вошло в минор именно потому, что его рассмотрели как багфикс.
Грустно. Это стоит как минимум подробно осветить в ченджлоге.
What do I do if I accidentally release a backwards incompatible change as a minor version?
As soon as you realize that you've broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it's appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version.
Кстати ещё для @sbmaxx задачка - обновить bem-core в песочнице
попробую вечерком обновить
Считается, что если обнаружено изменение, которое ломает обратную совместимость, то нужно выкатить патч с ревертом. А потом уже выкатить мажорный апдейт, если изменение полезное.
Но я ни к чему не призываю, нет.
Как узнают об этой проблеме все те пользователи bemhtml, которые не следят за этим репо?
У нас та же самая проблема возникает эпизодически в FF на убунте. При этом bemhtml
у нас нет, bem-core@2.7.0
Проблема усугубляется тем, что так и не нашли способа стабильного воспроизведения бага. Есть идеи, куда копать?
@h4 если падает с чем-то похожим на
RangeError: Maximum call stack size exceeded
at applyc (bundle.js:443)
at __$b37 (bundle.js:3822)
at __$g0 (bundle.js:4875)
at applyc (bundle.js:460)
at __$b89 (bundle.js:4225)
at applyc (bundle.js:573)
at __$b19 (bundle.js:3333)
at __$g0 (bundle.js:4688)
at applyc (bundle.js:460)
at __$b89 (bundle.js:4225)
то это определенно xjst
, т.е. BEMHTML либо BEMTREE, других вариантов нет.
@tadatuta видимо что-то другое. Вот такая ошибка
InternalError in / too much recursion
Стек вызовов потеряли, к сожалению.
@h4 если падает с чем-то похожим на
даёшь bem-xjst-2
с нормальной отладкой :)
@sbmaxx чтобы меня окончательно в дурку забрали?
@h4 почему?
@h4 grep 'InternalError in ' ./node_modules -r
?
@zxqfox это нативное браузерное сообщение
А, лол. Т.е. это тоже самое, что и первое.
видимо что-то другое. Вот такая ошибка
@h4 ;-)
@zxqfox вот только у нас нет ни BEMHTML ни BEMTREE. Только bem-core@2.7.0.
Может сегодня получится полный стектрейс раскопать.
с 2.6.0 работало. после обновления: