Именно, но к сожалению, уж очень много модулей в npm страдают этой болезнью. Мы например, релизим модули скриптом через отдельный бранч. Грубо говоря — создаём ветку release; удаляем из git-индекса всё; генерируем .gitignore с *(ignore all), там же добавляем исключения для релизных файлов, часто это лишь lib/**, readme.md, package.json, bower.json; дибавляем всё в гит; пушим в ветку release; создаем тэг. Таким образом у нас и npm чист, и bower пакет чист, а также все git releases.
Вот перечень команд:
[
`npm run bump`,
`git commit -a -m "v${version}"`,
`git push origin master`,
`git checkout -B release`,
`npm run build`,
`npm run ignorefiles`,
`npm publish`,
`git rm -r --cached .`,
`git add -A`,
`git commit -a -m "v${version}"`,
`git push origin release -ff`,
`git tag v${version}`,
`git push --tags`,
`git checkout master -ff`
]
Ёмаё, стыдно то как, а ведь на самом деле в pe2 не всё поддерживается. Беглым взглядом я пропустил, что это альтернатива к движкам с backtracking механизмом. Отсюда и сложность с внедрением backreference. Жаль старые комментарии редактировать нельзя на хабре.
Было также интересно почитать про irregexp. Lookbehind сделан на базе read_backward, действительно просто и удивляет почему раньше это не было сделано.
по алгоритму regexdna JavaScipt отрабатывает чуть быстрее, чем C++
В C++ версии используется re2 с lookbehind, atomic groups, possessive quantifiers, а в V8 это встроенная имплементация с довольно урезаным функционалом?
Да, мы уже выяснили, что удалять модули от которых зависят другие модули — это плохо. Теперь речь о том, как быть если авторы обновляют модуль с намеренно поломанным кодом.
Хм, версии дерева зависимостей фиксируются, на версиях которые у вас установлены на данный момент. Вас смутило полагаю поле "from", но это лишь мета информация изначального состояния дерева зависимостей. А bundledDependencies, как по мне, уже слишком "грубо", также как и добавление "node_modules" в репозиторий.
Когда используется относительная версия зависимости, тогда ответственность перекладывается на их авторов и вас. Ведь тогда вы просто надеетесь, что разработчики будут лишь улучшать модуль, а не наоборот. В таком случае пакетный менеджер вам ничего обещать не может. А так, есть же отличная вещь как shrinkwrap.
В данной ситуации, они сплошали лишь в том, что разрешали удалять модули и версии от которых зависели другие модули.
Раз про структуры и доступ к данным, наверное имелась ввиду индексация текста. Но показалось, что человек думал как можно сходу очень быстро из "миллиона" текста выудить нужные слова. То-есть препроцессинг вовсе не рассматривался.
Спасибо, такого ответа я и ожидал. В одном приложении понятен замысел, и когда перечитываешь реализацию, много становится понятно, зная для чего всё это.
Спасибо, а могли бы ещё на второй вопрос ответить? Хотя конечно может и дурацкий вопрос, но всё же — какие есть ОС не реального времени и в чем разница?
А в какой версии Node.js тестировался пример? Ведь функции уже давно захватывают из области видимости не больше чем нужно. Это значит, что gc удалит функцию "unused", a затем и "originalThing"
Ну как же, контроллер и компонент это разные вещи. Компонентом называют законченную единицу интерфейса/приложения — и он как раз состоит из контроллера, или шаблона, или только модели, также может другие ресурсы и компоненты включать в себя. Вообщем компоновать все это вещи можно как угодно. Здесь «компонент» был назван в контексте HMVC.
Компоненты можно тоже по принципу MVC строить, или одному из его вариаций.
> для маршрута может быть только один соответствующий контроллер
Это если только жестко привязываться к «Роут-Контроллер» архитектуре, но достаточно ввести между ними шаблон и уже можно комбинировать. И именно такой подход набирает популярность, так как он сочетает в себе и «Роут-Контроллер» вариант, и композицию.
Именно, но к сожалению, уж очень много модулей в npm страдают этой болезнью. Мы например, релизим модули скриптом через отдельный бранч. Грубо говоря — создаём ветку release; удаляем из git-индекса всё; генерируем .gitignore с
*(ignore all), там же добавляем исключения для релизных файлов, часто это лишьlib/**,readme.md,package.json,bower.json; дибавляем всё в гит; пушим в ветку release; создаем тэг. Таким образом у нас и npm чист, и bower пакет чист, а также все git releases.Ёмаё, стыдно то как, а ведь на самом деле в pe2 не всё поддерживается. Беглым взглядом я пропустил, что это альтернатива к движкам с backtracking механизмом. Отсюда и сложность с внедрением backreference. Жаль старые комментарии редактировать нельзя на хабре.
Было также интересно почитать про irregexp. Lookbehind сделан на базе read_backward, действительно просто и удивляет почему раньше это не было сделано.
Разумеется, по ссылке теста видны регекспы. Но ведь именно из-за поддержки этих фич, иначе устроен процессинг.
Ну тут должно быть просто, так как backtracking так и так есть, поэтому такая фича должна быть почти бесплатной.
А вот что вы имеете в виду под zero-width positive lookahead? Ведь любые
lookaheadиlookbehindэтоzero-width match?Наверняка имеется в виду такие штуки как https://github.com/codemix/fast.js
В C++ версии используется re2 с
lookbehind,atomic groups,possessive quantifiers, а в V8 это встроенная имплементация с довольно урезаным функционалом?bundledDependencies, как по мне, уже слишком "грубо", также как и добавление "node_modules" в репозиторий.В данной ситуации, они сплошали лишь в том, что разрешали удалять модули и версии от которых зависели другие модули.
Это чистая "Rust-овская версия" или уже с бриджем из ноды? Интерeсно какой оверхэд на вызов Rust методов?
"unused", a затем и"originalThing"> для маршрута может быть только один соответствующий контроллер
Это если только жестко привязываться к «Роут-Контроллер» архитектуре, но достаточно ввести между ними шаблон и уже можно комбинировать. И именно такой подход набирает популярность, так как он сочетает в себе и «Роут-Контроллер» вариант, и композицию.