拿下奇怪的前端报错(五):SyntaxError: Unexpected token ‘??=‘或‘xxx‘ - 基于容器搭建开发环境或许是更好的选择

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 在前端开发中,同时维护多个项目时可能会遇到不同Node.js版本的问题。低版本Node.js可能导致依赖无法安装或启动失败,而高版本Node.js则可能引起第三方库的兼容性问题。推荐使用Docker搭建独立的开发环境,以避免版本不一致带来的困扰。

在前端开发时,如果同时维护多个项目,跨越的年度又比较大,难免会使用多个Nodejs版本。有时候版本不对,不仅仅是安装会报错

1 依赖无法安装

一般情况下nodejs又向后兼容较好(除了部分三方包),所以安装依赖的时候,高版本node安装低版本包问题不大,但低版本Node安装高版本需求的包就会有问题。

版本过低报错

vue-i18n@9.14.1: The engine "node" is incompatible with this module. Expected version ">= 16". Got "14.21.2"

解决办法

如果只是安装问题,简单的忽略node引擎即可

yarn install --ignore-engines

// npm 类似

2 前端开发环境启动不了

前端框架由于都是第三方维护,很少把兼容性做的特别好,因为主要还是优化的开发体验、效率、性能等收益比较大的。这时候,如果版本过高/过低,都会出错,对新入行的小伙伴肯定是一个挑战,记得之前带应届生-他们也被这折磨的很糟糕,要是当时写篇文收集下可能更好,当时我也是带人新手-真有些内疚。

2.1 Nodejs版本过低

Nodejs版本过低,经常会遇到这个预期外符号的报错(需要注意是否为启动报错,也就是internal包,而不是业务代码文件的错!),大多数情况下是nodejs版本过低,内部的语法不兼容。

(node:24932) UnhandledPromiseRejectionWarning: SyntaxError: Unexpected token  

'??='

   at Loader.moduleStrategy (internal/modules/esm/translators.js:149:18)    

(Use `node --trace-warnings ...` to show where the warning was created)      

(node:24932) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().  

To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)

(node:24932) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

SyntaxError: Unexpected token '??='

   at wrapSafe (internal/modules/cjs/loader.js:1001:16)

   at Module._compile (internal/modules/cjs/loader.js:1049:27)

   at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)        

   at Module.load (internal/modules/cjs/loader.js:950:32)

   at Function.Module._load (internal/modules/cjs/loader.js:790:12)

   at Module.require (internal/modules/cjs/loader.js:974:19)

   at require (internal/modules/cjs/helpers.js:101:18)

   at Object.<anonymous> (D:\projects\cloudpcadmin\modules\voi-server\node_modules\.prisma\client\index.js:25:5)

   at Module._compile (internal/modules/cjs/loader.js:1085:14)

   at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10

2.2 Nodejs版本高

版本过高,同样会有问题,尤其是第三方涉及到构建过程的那些。很多库都慢慢的消失了,尤其是一些以前c完成的库,不少被js或者rust等取代,高版本的nodejs使用高版本的v8引擎,这时候ffi很多接口可能就变了,于是你会发现类似node-sass一类的每个node版本有个对应的数字.node文件,高版本就推荐用sass了。

Module build failed: Error: Node Sass does not yet support your current environment: Windows 64-bit with Unsupported runtime (115)

For more information on which environments are supported please see:

https://github.com/sass/node-sass/releases/tag/v4.14.1

   at module.exports (C:\Users\by4474\Documents\projects\cds-operate\node_modules\node-sass\lib\binding.js:13:13)

   at Object.<anonymous> (C:\Users\by4474\Documents\projects\cds-operate\node_modules\node-sass\lib\index.js:14:35)

   at Module._compile (node:internal/modules/cjs/loader:1358:14)

   at Module._extensions..js (node:internal/modules/cjs/loader:1416:10)

   at Module.load (node:internal/modules/cjs/loader:1208:32)

   at Module._load (node:internal/modules/cjs/loader:1024:12)

   at Module.require (node:internal/modules/cjs/loader:1233:19)

   at require (node:internal/modules/helpers:179:18)

   at getDefaultSassImpl (C:\Users\by4474\Documents\projects\cds-operate\node_modules\sass-loader\dist\index.js:198:10)

   at Object.loader (C:\Users\by4474\Documents\projects\cds-operate\node_modules\sass-loader\dist\index.js:80:29)

3 推荐用docker搭建开发环境

3.1 nvm频繁切换容易出错

因为nvm是全局的,在多个项目联调时,切换到14版本,启动一个服务,然后切换到20启动一个vite项目,中途某个进程崩了或者起了新工程,又不知道切换到了什么版本。这时候如果重启下某个项目(偶尔会因为缓存hmr出问题等),又会遇到报错,大脑会卡一下

3.2 docker是一个完全独立的环境

docker是一个完全独立的环境,各个nodejs共存,只需要把整个工程目录作为虚拟盘挂载到容器内,再使用容器内的node/npm就不会出现不一致的问题了。详细的流程可以参考之前的文章

《拿下奇怪的前端报错》:nvm不可用报错`GLIBC_2.27‘‘GLIBCXX_3.4.20‘not Found?+ 使用docker构建多个前端项目实践_docker gclib2.27-CSDN博客

链接

4 总结

稍微总结下

遇到难以理解的报错,首先确定报错文件,如果是项目文件就检查编译目标/语法

如果报错来自于nodejs的内部/第三方包,检查下nodejs版本

使用docker搭建开发环境是不错的选择


相关文章
|
2月前
|
Kubernetes 监控 数据中心
容器化与微服务:构建高效开发环境的双剑合璧
【10月更文挑战第20天】本文探讨了容器化技术(如Docker和Kubernetes)与微服务架构的结合,如何共同构建高效、灵活的开发环境。容器化解决了环境一致性、快速部署和资源隔离的问题,而微服务架构则提升了系统的可维护性和可扩展性。通过容器编排工具、CI/CD流程和服务网格,两者的结合进一步优化了开发和运维效率。文章还分享了实施这两项技术的最佳实践和职业心得。
|
2月前
|
缓存 前端开发 JavaScript
前端的全栈之路Meteor篇(二):容器化开发环境下的meteor工程架构解析
本文详细介绍了使用Docker创建Meteor项目的准备工作与步骤,解析了容器化Meteor项目的目录结构,包括工程准备、环境配置、容器启动及项目架构分析。提供了最佳实践建议,适合初学者参考学习。项目代码已托管至GitCode,方便读者实践与交流。
|
2月前
|
JavaScript 前端开发 Docker
前端的全栈之路Meteor篇(一):开发环境的搭建 -全局安装或使用容器镜像
本文介绍了如何搭建 Meteor 开发环境,包括全局安装 Meteor 工具和使用 Docker 镜像两种方法,以及创建和运行一个简单的 Meteor 项目的基本步骤。 Meteor 是一个全栈 JavaScript 框架,适用于构建实时 Web 应用程序。文章还提供了遇到问题时的解决建议和调试技巧。
|
2月前
|
Web App开发 缓存 前端开发
拿下奇怪的前端报错(六):多摄手机webrtc拉取视频流会导致应用崩溃,从而无法进行人像扫描
本文介绍了一种解决手机摄像头切换导致应用崩溃的问题的方法。针对不支持facingMode配置的四摄手机,通过缓存和序号切换的方式,确保应用在特定设备上不会频繁崩溃,提升用户体验。
|
2月前
|
存储 前端开发 NoSQL
拿下奇怪的前端报错(四):1比特丢失导致的音视频播放时长无限增长-浅析http分片传输核心和一个坑点
在一个使用MongoDB GridFS存储文件的项目中,音频和视频文件在大部分设备上播放时长显示为无限,而单独播放则正常。经调查发现,问题源于HTTP Range请求的处理不当,导致最后一个字节未被正确返回。通过调整请求参数,使JavaScript/MongoDB的操作范围与HTTP Range一致,最终解决了这一问题。此案例强调了对HTTP协议深入理解及跨系统集成时注意细节的重要性。
|
2月前
|
缓存 JavaScript 前端开发
拿下奇怪的前端报错(三):npm install卡住了一个钟- 从原理搞定安装的全链路问题
本文详细分析了 `npm install` 过程中可能出现的卡顿问题及解决方法,包括网络问题、Node.js 版本不兼容、缓存问题、权限问题、包冲突、过时的 npm 版本、系统资源不足和脚本问题等,并提供了相应的解决策略。同时,还介绍了开启全部日志、使用替代工具和使用 Docker 提供 Node 环境等其他处理方法。
573 0
|
2月前
|
存储 人工智能 前端开发
前端大模型应用笔记(三):Vue3+Antdv+transformers+本地模型实现浏览器端侧增强搜索
本文介绍了一个纯前端实现的增强列表搜索应用,通过使用Transformer模型,实现了更智能的搜索功能,如使用“番茄”可以搜索到“西红柿”。项目基于Vue3和Ant Design Vue,使用了Xenova的bge-base-zh-v1.5模型。文章详细介绍了从环境搭建、数据准备到具体实现的全过程,并展示了实际效果和待改进点。
142 2
|
2月前
|
JavaScript 前端开发 程序员
前端学习笔记——node.js
前端学习笔记——node.js
44 0
|
2月前
|
人工智能 自然语言处理 运维
前端大模型应用笔记(一):两个指令反过来说大模型就理解不了啦?或许该让第三者插足啦 -通过引入中间LLM预处理用户输入以提高多任务处理能力
本文探讨了在多任务处理场景下,自然语言指令解析的困境及解决方案。通过增加一个LLM解析层,将复杂的指令拆解为多个明确的步骤,明确操作类型与对象识别,处理任务依赖关系,并将自然语言转化为具体的工具命令,从而提高指令解析的准确性和执行效率。
|
2月前
|
存储 弹性计算 算法
前端大模型应用笔记(四):如何在资源受限例如1核和1G内存的端侧或ECS上运行一个合适的向量存储库及如何优化
本文探讨了在资源受限的嵌入式设备(如1核处理器和1GB内存)上实现高效向量存储和检索的方法,旨在支持端侧大模型应用。文章分析了Annoy、HNSWLib、NMSLib、FLANN、VP-Trees和Lshbox等向量存储库的特点与适用场景,推荐Annoy作为多数情况下的首选方案,并提出了数据预处理、索引优化、查询优化等策略以提升性能。通过这些方法,即使在资源受限的环境中也能实现高效的向量检索。