Docker 变得越来越流行,它可以轻便灵活地隔离环境,进行扩容,运维管理。对于业务开发者而言,随着持续集成的发展,对代码质量及快速迭代的要求也越来越高。
npm有两种方式安装第三方模块:本地安装和全局安装,使用哪种安装方式,取决于我们用npm模块来做什么。
这是第 66 篇不掺水的原创,想要了解更多,请戳上方蓝色字体:政采云前端团队 关注我们吧~ 本文首发于政采云前端团队博客:npm 依赖管理中被忽略的那些细节 https://www.zoo.te
Node.js 太火了,火到几乎所有前端工程师都想学,几乎所有后端工程师也想学。一说到 Node.js,我们马上就会想到“异步”、“事件驱动”、“非阻塞”、“性能优良”这几个特点,但是你真的理解这些词的含义吗?这篇教程将带你快速入门 Node.js,为后续的前端学习或是 Node.js 进阶打下坚实的基础。
作者:rianma | 腾讯web前端开发工程师 nodejs 社区乃至 Web 前端工程化领域发展到今天,作为 node 自带的包管理工具的 npm 已经成为每个前端开发者必备的工具。但是现实状况是,我们很多人对这个nodejs基础设施的使用和了解还停留在: 会用 npm install 这里(一言不合就删除整个 node_modules 目录然后重新 install 这种事你没做过吗?) 当然 npm 能成为现在世界上最大规模的包管理系统,很大程度上确实归功于它足够用户友好,你看即使我只会执行 inst
包管理器又称软件包管理系统,它是在电脑中自动安装、配制、卸载和升级软件包的工具组合,在各种系统软件和应用软件的安装管理中均有广泛应用。对于我们业务开发也很受益,相同的东西不必重复去造轮子。
然后,在写这系列文章时,发现有些操作需要用到package.json中的属性。然后,有些属性看起来人畜无害,但是用起来却需要查很多的资料。所以,就想着。写一篇或者两篇关于package.json的文章。
关于OPA(Open Policy Agent,开放政策代理),我最喜欢的一点是它可以与其他系统互操作。任何生成JSON的东西 — 现在大多数系统都可以 — 都可以为OPA提供呈现政策判断的输入。由于这种互操作性,你可以将OPA与基于容器的开发工具(如Docker)、基础设施配置工具(如Terraform)、容器编排平台(如Kubernetes)一起使用,而这还只是皮毛。
今天聊一个很少被提及的话题 —— 「依赖管理」(Dependencies Management) 。
这文描述了通过 Babel 生成 npm 包的最小设置。你可以在 GitHub 中看到 re-template-tag 中的设置。
每一个文件都有一个唯一的 inode,它包含文件的元信息,在访问文件时,对应的元信息会被 copy 到内存去实现文件的访问。
在我们写完第一个包之后,让我们看一看我们能写出来的其它包的例子。这一节会引导你创建一个简单的命令来将选中的文字替换为字符画(ascii art)。在你在单词“cool”选中的时候运行我们的命令,它会被替换为:
原文:Understanding differences between npm, yarn and pnpm 作者:Alex Kras 翻译:雁惊寒 本文作者对比了当前主流的包管理工具npm、yarn、pnpm之间的区别,并提出了合适的使用建议,以下为译文: NPM npm是Node.js能够如此成功的主要原因之一。npm团队做了很多的工作,以确保npm保持向后兼容,并在不同的环境中保持一致。 npm是围绕着语义版本控制(semver)的思想而设计的,下面是从他们的网站摘抄过来的: 给定一个版本号:主版本
有则笑话,如此讲到:“老丈人爱吃核桃,昨天买了二斤陪妻子送去,老丈人年轻时练过武,用手一拍核桃就碎了,笑着对我说:你还用锤子,你看我用手就成。我嘴一抽,来了句:人和动物最大的区别就是人会使用工具。……”。撇开这样特例场景,这句话还是非常用有道理的;毕竟从远古石器时期或更早,到如今,所言之语,所穿之衣,代步之车,所学的知识,所晓的常识.....皆是工具;可以说绝大部分人之间的差异(天才级除外),仅在于工具使用之优劣罢了。在工具的使用中,很多人极大程度上停留于会用层面,如若不遇到问题,几乎就处于停滞;这本身倒也没有问题,但可能因为没有透彻的了解,而错失了对该物可以拥有的想象力,从而错过了许多本该有的美好,如此的可惜。
于是决定写个(100 行代码不到的) cli 工具解决痛点,另外选择了 npm package 的方式,方便维护。
在上一篇npm init @vitejs/app的背后,仅是npm CLI的冰山一角[1]中,有提到我复习npm主要是从两个大方向来入手,所以这篇继续来讲讲package.json这部分知识,经过这轮复习,也发现了自己的很多不足,之前把常用的命令和配置玩熟了,却没关心npm已经有了更多新的玩法,而这些玩法却实实在在地在解决别人的问题。
大家好,我是 ConardLi。今天给大家分享一篇 JS 库打包的参考指南,如果你也在维护一些 JS 库,可以参考一下~
今天给大家分享一篇 JS 库打包的参考指南,如果你也在维护一些 JS 库,可以参考一下~
Monorepo这个词你应该不止一次听说了,像Vue3、Vite、ElementPlus等优秀开源项目都是使用Monorepo的方式管理项目,且这里说到的这几个项目都是采用pnpm作为包管理工具。
大家好,我是 winty。今天给大家分享一篇 JS 库打包的参考指南,如果你也在维护一些 JS 库,可以参考一下~
Searches the local package tree and attempts to simplify the overall structure by moving dependencies further up the tree, where they can be more effectively shared by multiple dependent packages. For example, consider this dependency graph: a +-- b <-- depends on c@1.0.x | `-- c@1.0.3 `-- d <-- depends on c@~1.0.9 `-- c@1.0.10 In this case, npm dedupe will transform the tree to: a +-- b +-- d `-- c@1.0.10 Because of the hierarchical nature of node's module lookup, b and d will both get their dependency met by the single c package at the root level of the tree. 复制代码 // npm7 以后微调 // 在保持上述原则的基础上,升级了如下细微的规则: In some cases, you may have a dependency graph like this: a +-- b <-- depends on c@1.0.x +-- c@1.0.3 `-- d <-- depends on c@1.x `-- c@1.9.9 During the installation process, the c@1.0.3 dependency for b was placed in the root of the tree. Though d's dependency on c@1.x could have been satisfied by c@1.0.3, the newer c@1.9.0 dependency was used, because npm favors updates by default, even when doing so causes duplication. Running npm dedupe will cause npm to note the duplication and re-evaluate, deleting the nested c module, because the one in the root is sufficient. To prefer deduplication over novelty during the installation process, run npm install --prefer-dedupe or npm config set prefer-dedupe true. Arguments are ignored. Dedupe always acts on the entire tree. Note that this operation transforms the dependency tree, but will never result in new modules being installed. Using npm find-dupes will run the command in --dry-run mode. Note: npm dedupe will never update the semver values of direct dependencies in your project package.json, if you want to update values in package.json you can run: npm update --save instead.During the installation process, the c@1.0.3 dependency for b was placed in the root of the tree. Though d's dependency on c@1.x could have been satisfied by c@1.0.3
“可是在我的机器上能工作啊!”这种场景可能是调试 bug 时最常见的问题。这通常是由于出错的机器和你自己的机器上系统的底层依赖性不同的结果。所以 yarn 和 npm 在引入了所谓的“lock file”,来跟踪你依赖项确切的版本。但是当你在开发要发布到 npm 的包时,应避免使用这类 lock file 。在本文中,我们将讨论为什么要这样。
有则笑话,如此讲到:“老丈人爱吃核桃,昨天买了二斤陪妻子送去,老丈人年轻时练过武,用手一拍核桃就碎了,笑着对我说:你还用锤子,你看我用手就成。我嘴一抽,来了句:人和动物最大的区别就是人会使用工具。……”。撇开这样特例场景,这句话还是非常用有道理的;毕竟从远古石器时期或更早,到如今,所言之语,所穿之衣,代步之车,所学的知识,所晓的常识…..皆是工具;可以说绝大部分人之间的差异(天才级除外),仅在于工具使用之优劣罢了。在工具的使用中,很多人极大程度上停留于会用层面,如若不遇到问题,几乎就处于停滞;这本身倒也没有
在介绍我们今天的主角 lerna 之前,首先了解下什么是 multirepo ?什么是 monorepo ?
作为开发人员,我们希望将开发环境与生产环境尽可能地匹配,以确保我们构建的内容在部署时能够正常工作。
Yarn 是 Facebook 开发的一款新的 JavaScript 包管理工具, 作为 NPM 的替代产品,主要是为了解决下面两个问题:
本指南旨在提供一些大多数库都应该遵循的一目了然的建议。以及一些额外的信息,用来帮助你了解这些建议被提出的原因,或帮助你判断是否不需要遵循某些建议。这个指南仅适用于 库(libraries),不适用于应用(app)。
问题引出 今天在运行之前的一个react工程时,浏览器上抛了一个奇怪的错误: Error: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons: 1. You might have mismatching versions of React and the renderer (such
Node 项目在项目根目录中名为 package.json 的文件中跟踪依赖关系和元数据。这是你项目的核心。它包含名称、描述和版本之类的信息,以及运行、开发以及有选择地将项目发布到 NPM 所需的信息。
下载地址:https://github.com/electron/electron/releases/tag/v12.0.2
📢📢📢号外,号外。我们的f_cli现在有了npm版本了。有两种主流的方式来访问
很长时间没有更新原创文章了,但是还一直在思考和沉淀当中,后面公众号会更频繁地输出一些前端工程相关的干货,希望对大家有一些启发,也希望在实际的工作当中帮助大家提升效率。
Dockerfile 是创建 Docker 镜像的起点,该文件提供了一组定义良好的指令,可以让我们复制文件或文件夹,运行命令,设置环境变量以及执行创建容器镜像所需的其他任务。编写 Dockerfile 来确保生成的镜像安全、小巧、快速构建和快速更新非常重要。
npm 之于 Node.js ,就像 pip 之于 Python, gem 之于 Ruby, pear 之于 PHP 。
npm 之于 Node ,就像 pip 之于 Python , gem 之于 Ruby , composer 之于 PHP 。
在 webpack 工程中,无论是使用 pnpm,还是 yarn,在运行项目之前都需要执行 pnpm i 或 yarn,这是在安装依赖项,将项目代码中引用的类库放在当前项目的 node_modules 目录下。
前段时间,我们邀请了我们“城内”(葡萄城)资深开发工程师刘涛为大家分享了一次干货满满的关于Electron线上公开课,在课程过程中有不少同学对于NPM的概念和用法有一些疑问,所以这次我们希望通过这篇文章来解答各位同学的问题。另外在介绍的基础上,我们还会适当的深入介绍下,如何在npm上发布第一个属于自己的包。那么,让我们马上开始吧!
本文会从零开始配置一个monorepo类型的组件库,包括规范化配置、打包配置、组件库文档配置及开发一些提升效率的脚本等,monorepo 不熟悉的话这里一句话介绍一下,就是在一个git仓库里包含多个独立发布的模块/包。
存了已经下载的每个版本的压缩包。本地缓存的内容可以通过npm cache ls命令进行查看。本地缓存的设计有助于减少安装时间。
本文是TypeScript的入门文章,将分别从下面四点对TypeScript进行介绍:
Node的包管理器 JavaScript缺少包结构的定义,而CommonJS定义了一系列的规范。而NPM的出现则是为了在CommonJS规范的基础上,实现解决包的安装卸载,依赖管理,版本管理等问题。 CommonJS是一个致力于构建统一的JS生态系统,它可以兼容web服务器、桌面应用、命令行应用、浏览器等。它定义了各种开发的规范和API不仅仅模块化相关的规范) 官网的说明: a group with a goal of building up the JavaScript ecosystem for we
一位用不好包管理器的前端,是一个入门级前端,一个用不好webpack的前端,是一个初级前端
在 JavaScript 编写中,我们尽量不要定义全局变量,封装函数尽量不要有副作用,因为全部变量的查询时间会比局部变量的查询慢,更是考虑在Node的环境中无法被垃圾回收的问题
在项目的前端开发中,对于绝大多数的小伙伴来说,当然,也包括我,不可避免的需要在项目中使用到一些第三方的组件包。这时,团队中的小伙伴是选择直接去组件的官网上下载,还是图省事直接在网上搜索,然后从一些来源不明的地方下载,我们就无法管控了。同时,我们添加的组件间可能存在各种依赖关系,如果我们没有正确下载引用的话,到最后可能还是无法正常使用。
每天,数以百万计的开发人员使用 npm 或 yarn 来构建项目。运行npm init或npx create- response -app等命令几乎构建JS项目的首选方式,无论是为客户端或服务器端,还是桌面应用程序。
领取专属 10元无门槛券
手把手带您无忧上云