Руководство по упаковке JavaScript

Код JavaScript, используемый в веб-среде, требует особого подхода, чтобы соответствовать высоким стандартам, предъявляемым ко всему коду, поставляемому в Fedora, оставаясь при этом полезным и совместимым с соглашениями, уже используемыми на миллионах веб-сайтов. Кроме того, некоторые библиотеки, обычно используемые в веб-среде, могут быть полезны и на стороне сервера (в nodejs или rubygem-execjs), поэтому важно упаковывать JavaScript так, чтобы он соответствовал стандартам, предъявляемым к локально исполняемому коду.

Обратите внимание, что этот раздел действительно относится только к библиотекам JavaScript, предназначенным для использования в веб-среде. Серверные среды выполнения JavaScript, такие как Node.js, имеют собственные руководства, а такое программное обеспечение, как GNOME, встраивающее JavaScript для расширений, также имеет собственные каталоги и политики.

Имя пакета библиотеки JavaScript ДОЛЖНО начинаться с js-, затем следует имя от upstream-проекта. Например: js-jquery.

Чтобы гарантировать наличие необходимых макросов RPM, все пакеты, предоставляющие JavaScript в %{_jsdir}, ДОЛЖНЫ иметь:

Чтобы гарантировать доступность необходимых каталогов, все пакеты, предоставляющие JavaScript в %{_jsdir}, ДОЛЖНЫ иметь:

Пакеты JavaScript НЕ ДОЛЖНЫ иметь Requires на какой-либо пакет конфигурации, специфичный для HTTP-демона, например web-assets-httpd, поскольку они могут использоваться любым HTTP-демоном.

Код JavaScript включён в состав общего фреймворка Web Assets. Поэтому %{_jsdir} по умолчанию доступен на веб-серверах, предоставляемых Fedora, по пути /_sysassets/javascript/.

Например, jQuery может быть установлен в %{_jsdir}/jquery/jquery-min.js, поэтому веб-приложения, которым нужно его использовать, могут просто включить этот тег HTML:

Тем не менее, веб-приложения могут захотеть сделать подкаталоги %{_jsdir} доступными в своём собственном каталоге через псевдонимы или символические ссылки для целей совместимости или чтобы устранить ненужные отклонения от upstream-проекта.

Если библиотека JavaScript обычно поставляется в виде минифицированного или скомпилированного кода, её СЛЕДУЕТ компилировать или минифицировать в рамках процесса сборки RPM, так как это приводит к более удобным в сопровождении пакетам. Если это приведёт к значительным трудностям, поставляемый в комплекте предварительно сгенерированный JS может быть включён в пакет с комментарием в spec-файле, объясняющим это решение. Это не отменяет требования проверять лицензии включённого в комплект кода.

При повторной генерации включённого в комплект JS следует использовать тот же компилятор или минификатор, что и в upstream-проекте, для компиляции или минификации кода в процессе сборки RPM. Если минификатор, используемый в upstream-проекте, невозможно включить в Fedora, может быть использован альтернативный минификатор. См. эту страницу со списком известных проблемных областей и предложениями по обходным решениям. Кроме того, нескомпилированная/неминифицированная версия СЛЕДУЕТ включаться вместе со скомпилированной/минифицированной версией.

Минифицированный JavaScript бесполезен для локально исполняемого JavaScript, так как весь смысл минификации заключается в сокращении времени передачи по HTTP. Поэтому JavaScript, не предназначенный для веб-среды (например, для Node.js или расширений GNOME Shell), НЕ ДОЛЖЕН минифицироваться.

Обычной практикой является включение в один минифицированный файл JavaScript кода из других библиотек JavaScript. В этом отношении JavaScript обрабатывается так же, как и другие библиотеки, поэтому Руководство по включению в комплект. Всё ещё ДОЛЖНО соблюдаться.

Иногда может существовать простая обёртка с другого языка (например, Ruby через rubygem-execjs или Java через rhino) или серверной среды выполнения JavaScript (например, Node.js) для чистой библиотеки JavaScript. Такие пакеты должны удалить включённый в комплект код библиотеки и вместо этого указывать на код, предоставляемый основным пакетом Fedora для этой библиотеки, и требовать его.

Некоторые модули Node.js включают части, которые могут использоваться в браузере или другими серверными движками JavaScript. Такие пакеты следует поставлять в виде одного SRPM, содержащего два пакета: