如今,几乎所有的Web服务或集成都是在Node.js运行时上完成的。Node.js是一个具有很多社区支持的灵活平台。我们甚至可以直接从Node.js创建xlsx,docx或pdf文档。所有主流云平台都可以使用Node.js作为其1级语言。
Node.js通过设计,可以使用node_modules结构来实现模块化。所有必需的模块都存储在node_modules目录中,并且我们可以在代码中的任何地方调用这些模块。
而现在,我们将在应用程序代码中使用这种模块化的方式。我看到的大多数应用程序都包含一个lib文件夹,其中存储了所有的JS文件。这些js文件使用相对路径导入所需区域。
const db = require("../db/")
const logging = require ("../../logging")
这种方法的主要问题是当我们改变服务文件的路径时,到DB的路径也应该改变。此外,格式是不可读的。我们将对文件的真实性感到困惑。
一个更好的方法是将应用程序设计为模块,例如DB,日志记录,错误等。假设你的应用程序名称为cms,那么使用scope可以更容易地表示模块。
require("@cms/db")
你可以单独开发模块,并将它们发布到任何npm服务器(公共/私有),并像任何其他模块一样使用它们。
如果你的应用程序需要日志记录模块:
npm install --save @cms/logging
如果你不想将应用程序分成几个部分,那么还有另一种方法。
将所需的模块保存在一个单独的文件夹中。假设有“@cms”。为每个模块使用单独的文件夹,让模块有一个单独的package.json。这样就可以成为一个有效的Node模块。
模块的package.json将如下所示
{
"name": "@cms/db",
"version": "1.0.1",
"description": "db module for CMS Application",
"main": "index.js",
"dependencies":{
"mysql" : "latest"
}
}
模块准备好了之后,就可以做一些脚本了。在“scripts”文件夹中添加install.js。
let fs = require('fs')
console.log('Creating symlinks ...')
if (fs.existsSync('node_modules/@cms')) {
console.log('link exists already ')
} else {
let source = '../@cms'
console.log(`creating link for ${source}`)
fs.symlinkSync(source, 'node_modules/@cms', 'junction')
console.log('done')
}
将此脚本添加到main package.json。
{
"name": "CMSApplication",
"version": "1.0.1",
"description": "Sample CMS Application",
"main": "index.js",
"scripts": {
"install": "node scripts/install.js",
"start": "node index.js"
},
"dependencies":{
"express" : "latest"
}
}
每当你执行npm安装时都会执行该脚本。因此,一旦所有其他节点模块被定义并且依赖关系被安装好了之后,它将创建从@cms文件夹外部到@cms文件夹内部node_modules的链接。所以你对外部@cms文件夹所做的任何更改都将反映到文件夹内部的node_modules。
你可以看到我们对@cms安装了符号链接。这不是一个快捷文件,不是在Linux中使用“ln”创建的硬链接。
在@cms内部,你可以看到我们在外部@cms文件夹中定义的模块。
这样你就实现了模块化。“@cms”文件夹是你源代码的一部分。然后你可以按正常方式导入所需的模块。
const {logger} = require("@cms/logging")
logger.info("Welcome to CMS Application")
当你希望应用程序执行时,运行“npm install”,然后运行“npm start”。
模块化是指把一个复杂的系统分解到一个一个的模块。模块化开发的优点:代码复用,让我们更方便地进行代码管理、同时也便于后面代码的修改和维护。一个单独的文件就是一个模块,是一个单独的作用域,只向外暴露特定的变量和函数。
CommonJS 是服务器端的模块化方案,nodeJs 就采用了这种方案。在 CommonJS 规范中,一个文件即一个模块,用module.exports和exports定义模块输出的接口,用require加载模块。在 requireJS 中用define定义模块,require载入模块,require.config用来配置路径。ES6 Module 主要使用export输出,import加载。
在很长的一段前端历史里,是不存在打包这个说法的。那个时候页面基本是纯静态的或者服务端输出的, 没有 AJAX,也没有 jQuery。Google 推出 Gmail 的时候(2004 年),XMLHttpRequest, 也就是我们俗称的 AJAX被拾起的时候
AMD 是 RequireJS 给出的模块加载方案。 支持递归依赖解析、模块异步加载,夜兼容 CommonJS 可以在 Node.js 里用。 虽然目前已经不再流行,很多站点更倾向于编写 ES Modules 并直接 Webpack 打包, 但 AMD 是完整的
CommonJS 模块输出的是一个值的拷贝,ES6 模块输出的是值的引用。CommonJS 模块是运行时加载,ES6 模块是编译时输出接口。export通过接口,输出的是同一个值。不同的脚本加载这个接口,得到的都是同样的实例。
本文包含两部分,第一部分通过简明的描述介绍什么是 CommonJS、AMD、CMD、UMD、ES Module 以及它们的常见用法,第二部分则根据实际问题指出在正常的 webpack 构建过程中该如何指定打包配置中的模块化参数。
这篇文章主要介绍了css模块化方案,css的模块化方案可能和js的一样多,下面简单介绍几种主要的模块方案,非常具有实用价值,需要的小伙伴可以参考下。css的模块化方案可能和js的一样多,下面简单介绍几种主要的模块方案
在模块化规范形成之前,JS开发者使用Module设计模式来解决JS全局作用域的污染问题。Module模式最初被定义为一种在传统软件工程中为类提供私有和公有封装的方法。在JavaScript中,Module模式使用匿名函数自调用 (闭包)来封装
众所周知,早期 JavaScript 原生并不支持模块化,直到 2015 年,TC39 发布 ES6,其中有一个规范就是 ES modules(为了方便表述,后面统一简称 ESM)。但是在 ES6 规范提出前,就已经存在了一些模块化方案
CommonJS 模块输出的是值的拷贝,也就是说,一旦输出一个值,模块内部的变化就影响不到这个值。ES6 Modules 的运行机制与 CommonJS 不一样。JS 引擎对脚本静态分析的时候,遇到模块加载命令import,就会生成一个只读引用。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!