Управление зависимостями Javascript и упаковка

Question

Я пытаюсь выяснить, как наилучшим образом управлять зависимостями файлов Javascript и сделать так, чтобы пакет 100% входил в интерфейсное приложение.Короче говоря, я создаю приложение, используя backbone.js вместе с некоторыми другими библиотеками.Я хочу организованную кодовую базу и хотел бы иметь возможность объявлять зависимости в каждом файле.В идеале эти объявления должны были бы а) определять порядок загрузки файлов браузером (в то время как в процессе разработки я хочу, чтобы файлы загружались отдельно) и определять порядок, в котором сценарии упаковки загружают сценарии для объединения (я собираюсь служитьодин файл для всего приложения).

Я читал на requirejs и commonjs, но я не уверен.

У меня есть простой сценарий оболочки, который использует cat <file> <file> <file> <file> > concatenated.fileделать то, что я хочу, но очень сложно поддерживать этот список файлов в актуальном состоянии и в правильном порядке.Было бы намного проще иметь возможность объявлять зависимость в начале каждого файла javascript, и упаковщик и загрузчики должны были бы с умом использовать эту информацию для объединения / загрузки сценариев.

Есть предложения?

Спасибо,

Луис

Answer 1

Я неравнодушен к себе.Это часть JavascriptMVC, но нет причин, по которым вы не можете использовать его с Backbone.js

Приятной особенностью этого является то, что он создает ваше приложение для производства, включая минимизацию ваших css и js и аккуратную упаковку всего этого.в 2 файла: production.css и production.js.

Он также может обрабатывать загрузку не JS-файлов, поэтому вы можете выполнять такие действия, как steal ('somefile.css'). then (function () {...});

Для файлов это очень похоже на то, что вы делаете на других языках:

steal(dep1, dep2, dep3).then(function () {
    // code 
});

Answer 2

Для сложных приложений внешнего интерфейса наилучшим выбором является формат асинхронного определения модулей (AMD).И это много замечательных загрузчиков, которые поддерживают AMD ( curl.js , RequireJS ).

Я рекомендую эту статью, чтобы узнать о современных подходах в управлении зависимостями javascript:

Написание модульного JavaScript с AMD, CommonJS & ES Harmony

Почему AMD?

Для упаковки учитывается CommonJS спецификаций, есть несколько реализаций, и это дело вкуса, но в любом случае я рекомендую выбирать инструменты, которые соответствуют некоторым из этих спецификаций.

Answer 3

Было бы намного проще иметь возможность объявлять зависимость в начале каждого файла javascript, и упаковщик и загрузчики должны были бы с умом использовать эту информацию для объединения / загрузки скриптов.

У меня была такая же идея несколько месяцев назад, и я работаю над решателем зависимостей для моего Resource Builder , который уже облегчает мне задачу (включая необходимость различать разработку и развернутую версию, снеобязательный параметр debug).

JsDoc Toolkit (и связанные с этим усилия), синтаксис которого поддерживается, например, Eclipse JSDT , обеспечивает @requires тег, чтобы вы могли использовать это.Но разрешение зависимостей все еще не тривиальная задача (как вы можете видеть в ResourceBuilder::resolveDeps()).(Конечная цель - использовать статический анализ кода для автоматического разрешения зависимостей без каких-либо тегов.)

Это уменьшит текущий

<script type="text/javascript" src="builder?src=object,types,dom,dom/css"></script>

до простого

<script type="text/javascript" src="builder?src=dom/css"></script>

Что касается асинхронных загрузчиков: то, что хорошо в асинхронных загрузчиках, это то, что они быстрые.Плохая вещь об асинхронных загрузчиках заключается в том, что - если они работают;все они основаны на нестандартном подходе - они настолько быстры, что вы не можете быть уверены, что функции, предоставляемые сценариями, доступны в следующих сценариях.Таким образом, ваш код должен выполняться их слушателями.Я рекомендую избегать их, если у вас в приложении нет функций, которые нужны только по требованию.