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

发布于 2024-11-16 14:40:57 字数 257 浏览 2 评论 0 原文

因此，您要在外部 .js 文件中创建一堆代码，这些代码需要 jQuery 及其一些插件、MooTools，或者可能是一些更深奥的库。显然，当您加载每个脚本时，实际的“包含”是在 HEAD 部分的主机 HTML 页面中完成的。

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

本宫微胖 2024-11-23 14:40:57

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 依赖项管理器的使用量比应有的要少，但如果您可以让您的库用户切换到一个，您就根本不必担心这一点：

< a href="http://javascriptmvc.com/docs.html#&who=stealjs" rel="nofollow">StealJS
Jingo
YUI 加载程序
Pyramid Dependency Manager

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

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

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

jQuery UI adds the dependencies of their widgets in the file header:

/*
* 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
*/

Now unfortunately JavaScript dependency managers are used way less than they should, but if you can make your libraries users switch to one you wouldn't have to worry about that at all:

Checking explicitly might be a good idea, too, since you can dynamically react if certain plugins are or are not available (e.g. either throw an exception if the jQuery UI dialog hasn't been found or just degrade gracefully and show a simple modal window):

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

That way your script doesn't have to break entirely if an optional dependency is not met.

回复收藏 0 原文

給妳壹絲溫柔 2024-11-23 14:40:57

对于 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直接链接到，抱歉......）

For the Visual Studio developers out there you may want to try blocks like these in your header

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

While this doesn't resolve your dependencies, it does document them, AND it gives you intellisense in Visual Studio...

See http://msdn.microsoft.com/en-us/library/bb385682.aspx, then look for References Directives (no a name or id to link directly to, sorry...)

回复收藏 0 原文

鸠书 2024-11-23 14:40:57

我的 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
//
////////////////////////////////////////////////////////////////////////////////

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

my js headers look like this:

////////////////////////////////////////////////////////////////////////////////
//
//  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
//
////////////////////////////////////////////////////////////////////////////////

Any dependencies are then quite clear to anyone on my team, and this has proven pretty reliable. As a (hopefully) secondary measure, I will always test for those dependencies at runtime and throw up an alert should a script not be included.

回复收藏 0 原文