设置
巴别塔6(^6.0.0),节点5.4.0,Express 4.13.x,
babel-node
和babel-register
都有一个警告,禁止在babel.io网站。基本上,像那样快速运输对生产来说太慢了。
因此,我已经设置了使用babel-cli
进行传输并运行预传输代码。
问题:
在开发过程中,重新编译所有代码并重新启动程序的速度太慢每一个变化。我也看不出如何将更改监视器(例如nodemon)设置为自动重新加载,因为我们现在运行的是传输的代码,而不是源代码(发生更改的地方)。
问题:
我们如何设置一种简单的方法来在开发期间的动态运输和生产前的运输之间切换?
我看到的大多数示例babel-node
和babel-register
都用于开发和生产,所以我不确定在为生产发货准备代码库的同时,用babel快速开发什么是好策略。
注意Github上许多非常流行的Node样板库仍在使用babel-node
和babel-register
作为生产代码,这可能是因为不久前,它们更容易用于建立快速重载的开发环境但是,使用babel-cli
同样简单,我建议立即将其用于开发和生产代码
在评论的帮助下,我找到了我的核心问题:
"在开发时,如何避免使用babel-cli
时源代码重建缓慢?"
与babel-node
和babel-register
提供的即时传输不同,babel-cli
在开发变化期间可以快速重新启动,它将代码预传输到构建目的地,然后可以在那里以es5格式单独运行代码。在开发过程中,在每次更改之间从源代码到构建代码的过程很慢,因为在重新启动服务器之前,您必须等待每个文件都被传输。
解决方案很简单-您只需要babel cli的watch
方法即可开箱即用。它可以监视所有源代码,并通过只重建在监视时更新的文件来快速更新构建代码
很抱歉,如果在阅读本文时,解决方案非常明显,但babel文档只显示单个文件的代码监视,并且目前Github上有很多流行的库专门用于监视整个文件夹的更改,所以我认为开箱即用的解决方案有点新,使用babel-cli
显然是babel-node
和babel-register
的一个选择。
所以,你所要做的就是使用这样的npm脚本:
"watch-files" : "babel src --watch --out-dir build"
并在进行更新时重新启动构建目录中的服务器(除非您设置了监视构建文件夹的自动重新加载)。
这要归功于@FelixKling和@aray12的评论,它们帮助我认识到babel-cli
即使在开发过程中也很容易使用。