Сгенерируйте package.json из скрипта Node, прочитав зависимости
У меня есть около 300 небольших и средних приложений Node, созданных моей командой за последние несколько лет, которые я пытаюсь очистить и систематизировать. Достаточно сказать, что мои заветные помощники не всегда дотошно использовали флаг --save с npm install, поэтому файлы package.json часто не отражают всех зависимостей. В других случаях они включают в себя пакеты, которые на самом деле не используются, потому что кто-то ДЕЙСТВИТЕЛЬНО использовал --save, а затем передумал о необходимости этих пакетов.
Все приложения используют одни и те же соглашения об именах файлов, так что мы можем быть благодарны за это.
Я мог бы написать скрипт, который читал исходный код в виде текстового файла, использовал регулярное выражение для поиска require и import и получал имена пакетов. Я сам могу разобраться с версиями. Но это кажется неэлегантным и неэффективным.
Когда я запускаю webpack в проекте, я заметил, что компилятор обрабатывает код, обнаруживая любой недопустимый синтаксис и, что более важно, любой импорт пакета, который недоступен, потому что он не был установлен.
Обычно меня бы раздражал процесс выполнения неизвестного скрипта, но, поскольку все эти скрипты написаны известными сущностями, я не беспокоюсь о злоупотреблениях. Мне в основном неясно, как такая программа, как webpack, анализирует .js файл, не обязательно выполняя его, и возвращает определенные ошибки с номерами строк.
Мне даже не обязательно автоматизировать процесс добавления отсутствующих зависимостей в файл package.json — многие из 300 приложений созданы правильно. Но это все равно сэкономило бы мне эоны времени, чтобы быстро обнаружить, чего не хватает.
Запуск скрипта, чтобы проверить, работает ли он, включает в себя виртуальную машину? Или это так же просто, как запустить скрипт из другого скрипта? Естественно, сами приложения не являются пакетами, поэтому простая попытка их require не сработает. Может быть, он использует JSLint?
Ответы 1
Webpack не запускает никаких скриптов, которые запускают ваш код, чтобы убедиться, что он работает. Он использует транспилятор Babel (который также не запускает ваш код).
Принцип работы компиляторов заключается в том, что они просматривают ваш код и проверяют, все ли синтаксически правильно, например, совпадение круглых или фигурных скобок, была ли объявлена используемая вами переменная, а в статически типизированных языках — правильность ваших типов. Пока/после этого они выдают код, который может использовать целевая система. В случае C компилятор берет ваш C-код и превращает его в машинный код или сборку, в зависимости от указанных вами параметров.
Разница между компилятором и транспайлером, как правило, заключается в том, что компиляторы переводят код вниз (по направлению к машинному уровню), а транспиляторы переводят код горизонтально. Представьте Typescript -> Javascript или, в данном случае, ES6+ Javascript -> ES[совместимый] Javascript. Это означает, что для того, чтобы Babel преобразовал ваш код ES6 во что-то более совместимое, он должен прочитать все ваши файлы и выполнить базовые проверки целостности. В частности, если он увидит, что вы импортируете код, он попытается получить доступ к модулю/файлам, потому что это инструкция. Если не получится, то выдаст ошибку.
По этой же причине вы увидите ошибки компиляции, но не ошибки времени выполнения, как и в других языках. Если бы Babel действительно запускал ваш код для проверки на наличие ошибок, он также мог бы найти ошибки времени выполнения. Однако код имеет много ветвей выполнения, поэтому найти их, а затем также задать условия для их выполнения — титаническая задача. Вот почему у нас есть инструменты для тестирования.
To more directly address your questions/concerns:
Does running a script to see if it works involve a VM?
Неа
Or is it as simple as running the script from another script?
Неа
I'm mainly unclear how it is that a program like webpack parses a .js file without necessarily executing it, and returns specific errors with line numbers.
Он использует Babel и
But this seems inelegant and inefficient.
к сожалению, именно это и делает Babel.
Примечание
Я дважды проверил документы Webpack и увидел, что у них есть собственный транспилятор, но он обрабатывает только операторы импорта/экспорта, и рекомендую использовать другой транспилятор, такой как Babel или Bublé, для транспиляции остальных, что я и имею в виду, когда говорю о том, как Webpack использует Babel.
См. начиная.
Это так элегантно объяснено - спасибо! Я очень ценю рукопожатие.