记录javascript库依赖关系的最佳实践

Best practice for documenting javascript library dependencies

本文关键字：最佳 关系 javascript 依赖 记录      更新时间：2023-09-26

因此，您正在一个外部.js文件中创建一堆代码，该文件需要jQuery及其一些插件、MooTools，或者一些更深奥的库。很明显，实际的"include"是在加载每个脚本时在HEAD部分的宿主HTML页面中完成的。

但是，作为可移植性的最佳实践，您的JavaScript.js文件中存在哪些内置功能或广泛采用的约定，以确保下一个使用您的代码的傻瓜记得还包括其他所需的库？

我正在寻求开发者社区的一些共识，所以请务必投票给最常见或你最熟悉的答案。

jQuery UI在文件头中添加其窗口小部件的依赖项：

/*
* jQuery UI Effects Bounce @VERSION
*
* Copyright 2011, AUTHORS.txt (http://jqueryui.com/about)
* Dual licensed under the MIT or GPL Version 2 licenses.
* http://jquery.org/license
*
* http://docs.jquery.com/UI/Effects/Bounce
*
* Depends:
* jquery.effects.core.js
*/

不幸的是，JavaScript依赖管理器的使用量远远低于应有的水平，但如果你能让你的库用户切换到一个，你就根本不必担心：

  • StealJS
  • Jingo
  • YUI装载机
  • 金字塔依赖关系管理器

显式检查可能也是一个好主意，因为如果某些插件可用或不可用，您可以动态地做出反应（例如，如果没有找到jQuery UI对话框，则抛出异常，或者只是优雅地降级并显示一个简单的模式窗口）：

if(!$.isFunction($.fn.dialog)) {
    throw "Could not find jQueryUI dialog. Please include jQuery UI";
}

这样，如果不满足可选的依赖关系，脚本就不必完全中断。

对于Visual Studio开发人员，您可能希望在您的头中尝试这样的块

/// <reference path="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.6-vsdoc.js" />
/// <reference path="thirdparty/ba-debug.js" />
/// <reference path="thirdparty/underscore.js" />

虽然这并不能解决您的依赖关系，但它确实对它们进行了文档记录，并在Visual Studio中为您提供了智能感知。。。

请参阅http://msdn.microsoft.com/en-us/library/bb385682.aspx，然后查找引用指令（没有名称或id可直接链接到，对不起…）

我的js头看起来像这样：

////////////////////////////////////////////////////////////////////////////////
//
//  src:        www.someDomain.com/js/modules/etc
//  author:     someguy
//  date:       6-22-11
//  intent:     what is the purpose / use of this module
//  package:    prototype parent
//  requires:   jquery.1.4.js
//              fancybox
//              etc
//
////////////////////////////////////////////////////////////////////////////////

任何依赖关系对我的团队中的任何人来说都是非常清楚的，这已经被证明是非常可靠的。作为（希望）次要措施，我将始终在运行时测试这些依赖关系，并在不包括脚本的情况下发出警报。

我一直认为软件工程师应该知道，或者至少应该被提醒，被迫知道他们在做什么。他们应该自己保存依赖项列表，并非常清楚他/她为什么需要它们。无论如何，页面中包含的js文件并不多。

我认为如果浏览器有jQuery和一些不错的插件，那就太好了，所以我们不需要在页面中包含它们来节省流量。

相关文章：