puppeteer-extra: Doesn't play nice with Webpack
Edit by @berstend:
see here for the workaround: https://github.com/webpack/webpack/issues/4175#issuecomment-450746682 and another one specific to the stealth plugin: https://github.com/berstend/puppeteer-extra/issues/93#issuecomment-712364816
Original issue:
When bundling I get this error:
WARNING in ./node_modules/puppeteer-extra/dist/index.esm.js 294:22-35 Critical dependency: the request of a dependency is an expression @ ./src/processor.js @ ./src/index.js @ multi @babel/polyfill ./src/index.js
And then at run-time:
A plugin listed ‘puppeteer-extra-plugin-stealth/evasions/chrome.runtime’ as dependency, which is currently missing. Please install it:
yarn add puppeteer-extra-plugin-stealth Note: You don't need to require the plugin yourself, unless you want to modify it's default settings.
Error: Cannot find module ‘puppeteer-extra-plugin-stealth/evasions/chrome.runtime’
Of course, puppeteer-extra-plugin-stealth
is already in the package.json
.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 4
- Comments: 60 (19 by maintainers)
Work-around is to import and apply the plugins manually:
I got this working locally but when I used webpack to bundle it and send it over to aws lambda, this line
StealthPlugin();
results to the error below. Adding “kind-of”: “^6.0.2” to the project’s package.json does not resolve the problem.
Error: Cannot find module ‘kind-of’ at a (/var/task/index.js:145:1835) at Function.o [as typeOf] (/var/task/index.js:145:1440) at i (/var/task/index.js:145:854) at e.exports (/var/task/index.js:145:371) at new n (/var/task/index.js:139:191) at new i (/var/task/index.js:133:12241) at e.exports (/var/task/index.js:133:12910) at Object.startBrowser (/var/task/index.js:127:99655) at Runtime.t.handler (/var/task/index.js:127:86330) at processTicksAndRejections (internal/process/task_queues.js:93:5) { code: ‘MODULE_NOT_FOUND’ }
I should note that while working on the playwright-supporting rewrite I realized that for improved type-safety it would make sense to ditch the dynamic custom imports, so I’m most likely doing that. This would mean that this webpack issue should evaporate in the next major release. 😄
@berstend I am getting the error:
This is my vue.config.js
babel.config.js:
This only happens if i use
StealthPlugin()
codeI’m getting a similar problem to this with
serverless-bundle
. Any ideas how to work around this withserverless-bundle
?The stealth plugin could require all evasions statically. This would cover most use-cases.
Users who need something more custom could manually import the ones that they need. This wouldn’t be much code and the full import list could be copied from the stealth plugin then edited.
Got it 😃 Anyway,
puppeteer-extra
should still be able to work with Webpack. It might be that the internal dependency system is just not aware of the bundler already taking care of the dependencies and a flag to disable the internal dependency resolution is sufficient.I also use electron-forge+webpack+typescript+puppeteer-extra. This worked, thank you!
I use (electron-forge+webpack+typescript+puppeteer-extra) got this error:
I finally got it work, here is what I did: add “externals” in webpack.main.config.ts
Hi guys, I made it working. Want to share what I got. Hope it works to y’all too.
Inside
vue.config.js
:Basically you have to expose these packages and include those inside
devDependencies
anddependencies
to make it working.just upgrade clone-deep version
@Seblor this is out of the scope of this webpack issue but the
iframe.contentWindow
evasion is known to cause issues, more context and workaround here: https://github.com/berstend/puppeteer-extra/issues/137#issuecomment-685680787It is, as you can see in the code of the
navigator.webdriver
evasion. Make sure you use the latest versions of everything.Did you try https://github.com/berstend/puppeteer-extra/issues/93#issuecomment-563159177 ? It is highly likely to work because it is pure ES6 with static imports.
@jstormail2 thanks for sharing your workaround 👍
I must admit listing the plugins manually isn’t the most prettiest thing in the world but great if it fixes the webpack issue. 😃
cc @Nisthar
I had the same issue. unlazy-loader solved this for me…
What is the purpose of the internal dependency management?
Could a simpler design work like this?
I use Webpack with Node because it’s a simpler way to use Babel, bundle
node_modules
and minify code.webpack.config.js
: