组态:
重现此问题的步骤:
我的代码是:
import pdflib from 'pdfjs-dist'
pdflib.PDFJS.workerSrc = './node_modules/pdfjs-dist/build/pdf.worker.entry.js'
完全符合https://github.com/mozilla/pdf.js/wiki/Setup-pdf.js-in-a-website#with -webpack中所述,
但是当我实际加载文档时,我在控制台中得到了Warning: Setting up fake worker.'
,这使得说明似乎不起作用。
此外,说明上的措词似乎是错误的,因为“ PDFJS.workerSrc _shall_设置为指向此文件”(当前措词)表示已自动设置,而“ PDFJS.workerSrc _should_设置为指向此文件”意味着您已经自行设置。
该示例代码也不是非常有用,因为它使用了到存储库( pdfjsLib.PDFJS.workerSrc = '../../build/webpack/pdf.worker.bundle.js';
)的相对路径,而导入PDFJS的人将无法做到这一点。
当我搜索不到1年的问题/ PR时,例如https://github.com/mozilla/pdf.js/pull/6595 ,它会自动加载工作程序脚本,但我似乎也感到困惑,但是该代码似乎不再存在于仓库中,因此设置和不设置workerSrc
导致假工人为我加载...假工人知道在哪里可以找到由webpack构建的工人脚本(例如1.bundle.js
是工人在bundle.js
是脚本),所以我很困惑,为什么一个真正的工人不能使用这个逻辑。
我尝试将workerSrc
指向创建的1.bundle.js
文件,甚至使用webpack的worker-loader实例化和替换PDFWorker
( pdflib.PDFJS.PDFWorker = require('worker!pdfjs-dist/build/pdf.worker.entry.js')
),但这没有也不起作用,所以我完全不知道该工人如何使用webpack
伪工人知道在哪里可以找到由webpack构建的工人脚本(例如,当bundle.js是脚本时,1.bundle.js是工人),所以我很困惑为什么真正的工人也不能使用此逻辑。
检查bundle.js是否包含worker-从那里加载页面的性能和大小是错误的。 整个pdf.worker.js文件应放置在单独的包中。
该示例代码也不是非常有用,因为它使用了人员要导入的存储库中的相对路径(pdfjsLib.PDFJS.workerSrc ='../../build/webpack/pdf.worker.bundle.js';)。 PDFJS显然无法做到(这不是一个非常有用的示例)。
您创建的pdf.worker.bundle.js文件为捆绑输出,其中包括pdf.worker.js模块(从pdfjs-dist导入)
问题的描述不清楚。 您可以提供完整的示例源代码吗?
检查bundle.js是否包含worker-从那里加载页面的性能和大小是错误的。 整个pdf.worker.js文件应放置在单独的包中。
检查了捆绑的代码,并可以确认它不包括工人。 如前所述,工作程序脚本捆绑为1.bundle.js
。 加载PDF后,将用于1.bundle.js
的脚本标记插入到我的<head>
标记中(不确定是否来自PDFJS或webpack)。
您创建的pdf.worker.bundle.js文件为捆绑输出,其中包括pdf.worker.js模块(从pdfjs-dist导入)
有没有使用Wiki中第一个(可能是首选的)方法从node_modules
加载工作脚本的示例? 在Wiki部分中:“工人应内置到单独的捆绑包中:提取文件“ ./node_modules/pdfjs-dist/build/pdf.worker.entry.js””
@yurydelendik您能否详细说明#6595中似乎不再存在于代码库中的工作程序的自动检测/加载? 我正在构建一个使用pdf.js的库,因此,如果有人必须导入pdf.js代码以使我的库正常工作,那将非常繁琐(管理依赖项的依赖项)。
问题的描述不清楚。 您可以提供完整的示例源代码吗?
我没有附加源代码,因为实际上没有太多有用或相关的内容,但这是〜50行的摘要: http : file
参数实际上是<input type='file' />
元素中的文件。
@yurydelendik您能否详细说明#6595中似乎不再存在于代码库中的工作程序的自动检测/加载?
此功能不适用于捆绑器/打包器。
我正在建立一个使用pdf.js的库,因此,如果有人必须导入pdf.js代码以使我的库正常工作,那会有点烦人(管理依赖项的依赖项)。
到目前为止,我们还没有找到可以正确管理Web Worker的捆绑器,并且我们不想让webpack或browserify优先使用-我们在同时支持这两个方面存在问题。
解决方案是管理依赖关系的依赖关系并非易事。 但是请记住,有效地解析和呈现PDF并非易事。 如果您放弃使用Web Worker,而您可以自由地这样做,则UI性能将受到影响,这将是您的权衡。
我没有附加源代码,因为实际上没有太多有用或相关的内容
您可以发布一个小的库示例,以说明您要实现的目标。 提供的代码段没有用,因为它们不是:可运行的,而不是您要执行的操作-库。
我遇到了同样的问题。 请参阅https://cdn.kidoju.com/support/viewer/index.html。
可以在https://github.com/kidoju/Kidoju-Help中找到该代码build
cmd文件。
另请参阅https://github.com/kidoju/Kidoju-Help/issues/2。
此功能不适用于捆绑器/打包器。
没意识到👍
到目前为止,我们还没有找到可以正确管理Web Worker的捆绑器,并且我们不想让webpack或browserify优先使用-我们在同时支持这两个方面存在问题。
解决方案是管理依赖关系的依赖关系并非易事。 但是请记住,有效地解析和呈现PDF并非易事。 如果您放弃使用Web Worker,而您可以自由地这样做,则UI性能将受到影响,这将是您的权衡。
@yurydelendik我同意你的看法,但我认为不需要进行权衡。 Webpack拥有工作程序加载器,而Browserify拥有webworkify -是否不检测捆绑程序系统并使用一个或另一个完全解决此问题?
似乎可以在这里完成: https :
Webpack中的var worker = require('worker!../pdf.worker.entry.js')
或
var worker = require('webworkerify')('../pdf.worker.entry.js')
在browserify中。
如果您认为我能做到这一点,我很乐意为此写一份PR。
您可以发布一个小的库示例,以说明您要实现的目标。 提供的代码段没有用,因为它们不是:可运行的,而不是您要执行的操作-库。
我附带的代码段是目前库中的所有代码( pdf-to-dataURL
)。 如果@jlchereau的示例不够好,我可以举一个使用该代码段的简单示例(它似乎不需要NPM提供pdfjs-dist
,因此不确定其准确性)
Webpack拥有工作程序加载器,而Browserify拥有webworkerify -是否不检测捆绑程序系统并使用一个或另一个完全解决此问题?
是的,我在#6785尝试过,后来在#6791尝试过,然后又恢复了。 拥有require('worker!...
会导致browserify出现问题,而导致require('webworkerify')(...)
在webpack中。
如果您认为我能做到这一点,我很乐意为此写一份PR。
是的,拥有良好的公关工作真的很不错。 到目前为止,pdfjs-dist可以以某种方式与webpack一起使用,并与system.js和node.js一起使用browserify; 我们将尝试保持这种方式。 谢谢。
还要注意,如果worker由于某种原因(安全性或仅是旧版浏览器)不可用,它将以脚本标签的形式加载代码。 我打算为PDFWorker添加重载的构造函数,该构造函数将接受Web worker作为参数-这可能为某些webpack / browserify用例提供替代解决方案。
顺便说一句,webpack具有entry-loader,可与workerSrc一起使用
是的,我在#6785尝试过,后来在#6791尝试过,然后又恢复了。 拥有require('worker!...)会导致browserify出现问题,而在webpack中会出现require('webworkerify')(...)。
但是您的__webpack_require__
不会在这里检查吗
https://github.com/mozilla/pdf.js/pull/6785/commits/79c2f69c3288494c5ce2809182c896484bf4be5c#diff -5f93a8d6c23cf0a169c6ee7347477ce8R30阻止browserify解析该语句? (不确定ensure
部分是否引起问题)
是的,拥有良好的公关工作真的很不错。 到目前为止,pdfjs-dist可以以某种方式与webpack一起使用,并与system.js和node.js一起使用browserify; 我们将尝试保持这种方式。 谢谢。
下周晚些时候我可能会讲到这一点-是否可以运行测试来检查各种捆绑程序/平台?
我打算为PDFWorker添加重载的构造函数,该构造函数将接受Web worker作为参数-这可能为某些webpack / browserify用例提供替代解决方案。
我认为这将是一个绝佳的选择! 具体来说,如果它可以接受Worker
类,则webpack伙计可以使用类似的东西: webworkify-webpack和webworkify并仅将loader / Worker作为参数传递。 原来如此
var worker = new WorkerFromArgs('../pdf.worker.entry.js')
在重载的情况下。
这会将工作加载程序逻辑的配置卸载到用户区域,因此不需要将平台/捆绑程序检查到pdf.js中的潜在混乱PR(在任何情况下,用户都需要安装适当的加载程序)
但我得到警告:设置假工人。 在我实际加载文档时在控制台中,这使得说明似乎不起作用。
很棒,但是如上所述,没有完整的示例就无法解决该问题。 我们要关闭这一个并等待PR吗?
@jlchereau举了一个例子https://github.com/mozilla/pdf.js/issues/7612#issuecomment -245973303在这里您可以类似地在控制台中看到Warning: Setting up fake worker
,如果需要的话,我可以给出另一个例子
这个问题仍然很重要,因为workerSrc
在当前的实现中应该可以,但是不能。
无论如何,PR都可以解决此问题,因此在此之前不应该不进行跟踪吗?
我也想听听您对以上问题的反馈,然后再开始PR(关于为什么为什么当您尝试检查__webpack_require__
时browserify会抱怨,就像我在PR中一样,并且如果有任何测试,我应该同时运行以测试所有捆绑器/平台)
@ agilgur5 ,您说:
The snippet I attached is all of the code that would be in the library for now (pdf-to-dataURL).
I could make a quick example that uses that snippet if <strong i="7">@jlchereau</strong>'s example isn't good enough
(it doesn't seem to require pdfjs-dist from NPM, so not sure about the accuracy of it).
请参阅https://github.com/kidoju/Kidoju-Help/blob/master/src/main.js,并在适当时取消注释:
require('../web/viewer.css');
require('../web/compatibility.js');
// require('pdfjs-dist/web/compatibility.js');
require('../web/l10n.js');
window.pdfjsDistBuildPdf = require('../build/pdf.js');
// window.pdfjsDistBuildPdf = require('pdfjs-dist/build/pdf.js');
// require('../web/debugger.js');
require('./viewer.js');
我一直尝试两者的原因是https://github.com/mozilla/pdf.js/blob/master/web/viewer.js和https://github.com/mozilla/pdfjs-dist/blob/master/ web / pdf_viewer.js是不同的,我认为与保留来自同一源/版本的所有文件更相关。
无论如何,就工人而言,两者都表现出相同的行为。
@yurydelendik似乎您还没有签出@jlchereau的示例。 我还制作了pdf-to-dataURL作为一个很小的软件包,它展示了这个bug。
我打算为PDFWorker添加重载的构造函数,该构造函数将接受Web worker作为参数-这可能为某些webpack / browserify用例提供替代解决方案。
是否有任何更新? 正如我之前提到的,我觉得这是一个比我提出的解决方案更好的解决方案(您没有回答我提出的问题,因此我无论如何也无法真正做出PR),并且对于将来的用例和解决方案而言,它的通用性更高。其他捆绑器。
我在webpack项目中遇到了同样的问题,但是我以不同的方式解决了它。 我没有依赖webpack的捆绑程序或加载程序,而是利用CopyWebpackPlugin将工作程序源复制到构建目录中。
在我的查看器中:
import pdfjsLib from 'pdfjs-dist';
if (process.env.NODE_ENV !== 'production') {
//in dev, get it from the node_modules directory
//NOTE: don't use the "entry" file -- the script will fail and the web worker will not be used
pdfjsLib.PDFJS.workerSrc = `${process.env.APP_ROOT}/node_modules/pdfjs-dist/build/pdf.worker.js`;
} else {
//in prod, get it from the build directory
pdfjsLib.PDFJS.workerSrc = `${process.env.APP_ROOT}/build/pdf.worker.js`;
}
在webpack.config.js
:
const CopyWebpackPlugin = require('copy-webpack-plugin');
return {
//... rest of config omitted
plugins: [{
new CopyWebpackPlugin([{
from: 'node_modules/pdfjs-dist/build/pdf.worker.js',
to: 'pdf.worker.js'
}])
}]
}
@ agilgur5 ,我只是遇到了这个问题,这是因为我正在使用CommonsChunkPlugin。 在我的情况下,网络工作人员正在加载,但遇到了错误Uncaught ReferenceError: webpackJsonp is not defined
(因为该代码被拉到一个公共块中,并且对工作人员不可用)。 这导致工作人员提早退出并退回到伪造的实施中。
您不能使用CommonsChuckPlugin或使用建议的解决方案@ctowler 。
希望这能解决您的问题。
大家好,
为了使pdf.js与Webpack配合使用,我付出了很多努力。 关键是我不希望工作人员位于单独的文件中。
如果有人遇到以下问题:
Warning: Setting up fake worker.
消息,我将raw-loader
在package.json中,以便能够将文件导入为纯文本格式。
"raw-loader": "latest",
我以某种方式配置Webpack,以便通过raw-loader
加载pdf.worker.js。
module: {
rules: [
{
test: /pdf\.worker(\.min)?\.js$/,
use: 'raw-loader',
},
{
test: /\.(js|jsx)$/,
exclude: [/node_modules/, /pdf\.worker(\.min)?\.js$/],
use: 'babel-loader',
},
],
},
现在是棘手的部分。 将工作程序传递给PDF.js的唯一方法是通过workerSrc
设置。 不幸的是,做类似
pdfjsLib.PDFJS.workerSrc = require('pdfjs-dist/build/pdf.worker');
将无法正常工作。
但! 我们可以通过Blob
s动态创建URL,也可以根据字符串动态创建Blob
s!
因此,对我来说可行的解决方案是:
const pdfjsLib = require('pdfjs-dist');
const pdfjsWorker = require('pdfjs-dist/build/pdf.worker.min');
const pdfjsWorkerBlob = new Blob([pdfjsWorker]);
const pdfjsWorkerBlobURL = URL.createObjectURL(pdfjsWorkerBlob);
pdfjsLib.PDFJS.workerSrc = pdfjsWorkerBlobURL;
🎉:D
js
require.ensure([], function () {
var worker;
worker = require('./pdf.worker.js');
callback(worker.WorkerMessageHandler);
});
pdf.worker.min
,Webpack就会因为这个东西而感到困惑并包括pdf.worker.js
。 更糟糕的是,即使PDF.jspdf.worker.js
。 那么我们该如何处理这些废话呢?js
new webpack.NormalModuleReplacementPlugin(
/pdf\.worker(\.min)?\.js$/,
path.join(__dirname, 'node_modules', 'pdfjs-dist', 'build', 'pdf.worker.min.js'),
),
/pdf\.worker(\.min)?\.js$/
匹配的文件-更具体地说, pdf.worker.js
和pdf.worker.min.js
都将被替换为缩小版本。ew 希望这对任何人有帮助!
@wojtekmaj我们为Webpack用户添加了pdfjs-dist / webpack以实现零配置。 您可以在https://github.com/yurydelendik/pdfjs-react上查看其用法
@yurydelendik谢谢,是的,我意识到了这一点。 尽管我没有设法使其完全正常运行,并且我面临着许多问题,因为对我来说,以一个编译文件结尾是必须的。
这是因为我正在开发react-pdf,并且它对于我的用户来说必须非常容易安装。 package.json + import,繁荣,仅此而已。
我无法告诉他们自己自己计算pdf.worker.js,更不用说编写有关webpack,browserify和其他内容的说明了。
我的用户必须非常容易地安装它。 package.json + import,繁荣,仅此而已。
@wojtekmaj我不太了解您的要求。 我看不到如何在React组件项目中添加pdfjs-dist和使用pdfjs-dist / webpack是不可能的。 用户将只包括前者(一个组件项目)。
对我来说,以一个编译文件结尾是必须的。
一个编译文件不是您想要的:a)页面启动,b)缓存和传输大小,c)worker可能出现的问题-但这是您的选择。
@yurydelendik
哦,对不起,我看错了您以前的帖子。 我以为您在谈论/ examples / webpack,这是完全不同的事情。 绝对应该更新为使用pdfjs / webpack! 谢谢!
还有一件事...使用pdfjs-dist / webpack不会阻止pdf.js本身尝试单独要求pdf.worker.js。 我最终得到:
当我将pdf.worker定义为条目之一时,甚至变得更糟,我最终得到:
我该如何解决这个问题?
使用上面的我的react-pdf示例运行yarn build
,我得到以下文件:
...
File sizes after gzip:
198.42 KB build/7b14afe24b211632ecc8.worker.js
197.76 KB build/static/js/0.974e8de4.chunk.js
130.14 KB build/static/js/main.5a79c9e3.js
4.19 KB build/static/css/main.d852b162.css
...
这很正常:该应用程序是``build / static / js / main.5a79c9e3.js''(pdf.js加上react),``build / static / js / 0.974e8de4.chunk.js''是pdf.worker.js后备代码当禁用worker并使用'build / 7b14afe24b211632ecc8.worker.js'worker代码时加载。 我想念什么吗?
@wojtekmaj请准备用户测试应用程序的完整
PDFJS.workerSrc ='scripts.bundle.js';
PDFJS.getDocument(getPdfName).then((pdfFile:any)=> {
this.pdfFile = pdfFile;
this.renderPdfIntoPages(pdfFile,getPdfPages,this.pdfReady);
});
分配这样的值,然后它的工作...
谢谢...
使用@yurydelendik解决方案时,如果有人得到window
未定义错误,请输入
globalObject: 'true'
在您的webpack配置的output
段中。
webpack中似乎存在一个错误,当使用web workers
时,webpack会将window
对象弄乱。 因此,上述技巧解决了该问题。
@wojtekmaj :
感谢您的解决方案! 它在Chrome,FF,Edge,Opera,Safari中对我来说效果很好。 但是当您将它从babel-loader
排除时,它不会被转换回ES5。 所以我在IE11中遇到问题,依此类推。 还是我在那里缺少什么?
我在这里可能做错了什么,所以请纠正,聪明的人,但是我采用了@wojtekmaj的思路,并使它的工作更加简单。
在webpack.config中:
...
{
test: /pdf\.worker(\.min)?\.js$/,
loader: 'file-loader'
},
然后,在我的代码中:
import PDFJS from 'pdfjs-dist';
import PDFJSWorker from 'pdfjs-dist/build/pdf.worker.min';
PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
...
配置:
嘿,我在使用webpack和pdfjs时遇到了一些麻烦(它是工作人员)。
由于webpack的原因,我在尝试加载worker时遇到此错误:
我找不到任何解决方法。
vendor_pdfjsWorker存在,但不存在。 就我而言,我希望工作人员与pdf.js位于同一位置。
最初,我尝试更改workerSrc,如wojtekmaj所解释。 但是pdfjs并没有使用我的workerSrc来获取工作程序。 Webpack解析更改pdfjs(l.9915):
if (typeof window === 'undefined') {
isWorkerDisabled = true;
if (typeof require.ensure === 'undefined') {
require.ensure = require('node-ensure');
}
useRequireEnsure = true;
} else if (typeof require !== 'undefined' && typeof require.ensure === 'function') {
useRequireEnsure = true;
}
进入
if (typeof window === 'undefined') {
isWorkerDisabled = true;
if (typeof require.ensure === 'undefined') {
require.ensure = require('node-ensure');
}
useRequireEnsure = true;
} else if (true) {
useRequireEnsure = true;
}
因此,设置了fakeWorkerFilesLoader(l.9932):
fakeWorkerFilesLoader = useRequireEnsure ? function () {
然后,我的workerSrc无法得到,因为定义了fakeWorkerFilesLoader:
var loader = fakeWorkerFilesLoader || function () {
return (0, _dom_utils.loadScript)(_getWorkerSrc()).then(function () {
return window.pdfjsWorker.WorkerMessageHandler;
});
};
在我的webpack配置中,我添加了:
module: {
noParse: (filename) => {
return /\\node_modules\\pdfjs-dist\\build\\pdf.js/.test(filename);
},
rules: [
.......................
]
},
然后我有这个错误:
它告诉我我的脚本“ ecm_viewer.worker.js”不存在。
我在webpack配置中添加了一个条目:
entry: {
'ecm_viewer': getFileList(),
'ecm_viewer.worker': './node_modules/pdfjs-dist/build/pdf.worker.entry',
}
即使我删除了noParse函数,它也可以完美地工作。 在添加此noParse Webpack选项之前,我无法调试实际错误。
我不知道是否在正确的地方写这个; 我可以将帖子移到stackoverflow或其他地方。 有一天可能会对某人有所帮助。
我在webpack项目中遇到了同样的问题,但是我以不同的方式解决了它。 我没有依赖webpack的捆绑程序或加载程序,而是利用CopyWebpackPlugin将工作程序源复制到构建目录中。
在我的查看器中:
import pdfjsLib from 'pdfjs-dist'; if (process.env.NODE_ENV !== 'production') { //in dev, get it from the node_modules directory //NOTE: don't use the "entry" file -- the script will fail and the web worker will not be used pdfjsLib.PDFJS.workerSrc = `${process.env.APP_ROOT}/node_modules/pdfjs-dist/build/pdf.worker.js`; } else { //in prod, get it from the build directory pdfjsLib.PDFJS.workerSrc = `${process.env.APP_ROOT}/build/pdf.worker.js`; }
在
webpack.config.js
:const CopyWebpackPlugin = require('copy-webpack-plugin'); return { //... rest of config omitted plugins: [{ new CopyWebpackPlugin([{ from: 'node_modules/pdfjs-dist/build/pdf.worker.js', to: 'pdf.worker.js' }]) }] }
这解决了我的团队一直在寻找WEEKS的问题。 谢谢@ctowler :D <3
使用@yurydelendik解决方案时,如果有人得到
window
未定义错误,请输入globalObject: 'true'
在您的webpack配置的
output
段中。
webpack中似乎存在一个错误,当使用web workers
时,webpack会将window
对象弄乱。 因此,上述技巧解决了该问题。
@vivektiwary我ReferenceError: Can't find variable: window
我确实将globalObject:'true'
设置放入Webpack.config文件中,但该应用程序现在根本无法加载。 您确定它有效吗?
使用@yurydelendik解决方案时,如果有人得到
window
未定义错误,请输入globalObject: 'true'
在您的webpack配置的
output
段中。
webpack中似乎存在一个错误,当使用web workers
时,webpack会将window
对象弄乱。 因此,上述技巧解决了该问题。@vivektiwary我
ReferenceError: Can't find variable: window
我确实将
globalObject:'true'
设置放入Webpack.config文件中,但该应用程序现在根本无法加载。 您确定它有效吗?
是@taihuuho ,您是否将其放在配置的输出obj中?
顺便说一句,你得到什么错误?
@vivektiwary使用该pdfjs-dist/webpack
时出现此错误ReferenceError: Can't find variable: window
pdfjs-dist/webpack
我在这里可能做错了什么,所以请纠正,聪明的人,但是我采用了@wojtekmaj的思路,并使它的工作更加简单。
在webpack.config中:
... { test: /pdf\.worker(\.min)?\.js$/, loader: 'file-loader' },
然后,在我的代码中:
import PDFJS from 'pdfjs-dist'; import PDFJSWorker from 'pdfjs-dist/build/pdf.worker.min'; PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker; ...
我最终使用了@varunarora的解决方案,并且效果很好。 显然,此Webpack文档页面https://github.com/mozilla/pdf.js/tree/master/examples/webpack似乎并不适合所有人
无需编辑webpack配置:
PDFJS.GlobalWorkerOptions.workerSrc = require('!!file-loader!pdfjs-dist/build/pdf.worker.min.js').default;
要么
import PDFJS from 'pdfjs-dist';
import PDFJSWorker from '!!file-loader!pdfjs-dist/build/pdf.worker.min.js';
PDFJS.GlobalWorkerOptions.workerSrc = PDFJSWorker;
并且当然要确保您已安装file-loader
。
我正在使用电子伪造,这导致文件加载器将工作程序放在一个目录中,因此我不得不使用
PDFJS.GlobalWorkerOptions.workerSrc = '../' + require('!!file-loader!pdfjs-dist/build/pdf.worker.min.js').default;
使用文件加载器在某种程度上会对我的应用程序的其余部分产生副作用,因为其他方面也需要它。 因此,我发现的另一种方法是从CDN获取pdf.worker.js文件:
参见此处: https :
最有用的评论
我在webpack项目中遇到了同样的问题,但是我以不同的方式解决了它。 我没有依赖webpack的捆绑程序或加载程序,而是利用CopyWebpackPlugin将工作程序源复制到构建目录中。
在我的查看器中:
在
webpack.config.js
: