Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(initialize-node): __dirname in some envrioments #7933

Closed
wants to merge 1 commit into from

Conversation

codydaig
Copy link

This patch fixes __dirname pointing to / in some envrioments by
trying process.cwd() if __dirname returne undefined.

Issues: #7085 #7932

What kind of change does this PR introduce?

Fixes #7932 where certain node environments with webpack don't place nicely to __dirname.

Did you add tests for your changes?

No. This is very difficult to reproduce in simple environments. This change only affects those where __dirname returns undefined on initialization.

If relevant, did you update the documentation?

No relevant documentation updates needed.

Summary

When __dirname points to / it falls back to process.cwd to get the projectRoot on initialization.

Does this PR introduce a breaking change?

No.

@OrKoN
Copy link
Collaborator

OrKoN commented Jan 27, 2022

@jackfranklin could you please take a look?

@OrKoN
Copy link
Collaborator

OrKoN commented Jan 28, 2022

Why does it work with process.cwd()? I assume that the cwd is not the Puppeteer's installation folder in node_modules, is it? In those environments, do you still rely on Puppeteer to download the browser binary?

@OrKoN
Copy link
Collaborator

OrKoN commented Jan 28, 2022

Does it work if you specify the path via PUPPETEER_DOWNLOAD_PATH or skip download PUPPETEER_SKIP_CHROMIUM_DOWNLOAD?

@codydaig
Copy link
Author

I don't think you can just rely on PUPPETEER_DOWNLOAD_PATH because it's starting out by setting puppeteerRootDirectory to undefined (if __dirname is root) and that errors when creating a new BrowserFetcher passing in the project root (Launcher.ts line 808). I could be mistaken and can double check this later today.

You are correct that process.cwd() doesn't return the puppeteer root Directory, but the directory in which they are in, but regardless, i believe they end up resolving the same after pkgDir.sync() finding the project root.

I know with this, it was able to find the chromium install inside the node_modules folder. I can double check the Download path env variable in a bit and see if that resolves it.

This patch fixes __dirname pointing to / in some envrioments by
trying process.cwd() if __dirname returne undefined.

Issues: puppeteer#7085 puppeteer#7932
@OrKoN OrKoN requested review from OrKoN and removed request for jackfranklin February 7, 2022 09:11
@OrKoN
Copy link
Collaborator

OrKoN commented Feb 7, 2022

codydaig@ actually, have you tried to re-configure webpack to have the proper __dirname? https://codeburst.io/use-webpack-with-dirname-correctly-4cad3b265a92 I am a bit hesitant to merge the CL as is as it'd be installing chromium into the cwd instead of the node_modules/puppeteer folder. It'd be great if you could share a repro as I'd like to get some better understanding of how it works.

@my-lalex
Copy link

Why not use the require.resolve Node API to get the puppeteer package location?

@OrKoN
Copy link
Collaborator

OrKoN commented Feb 11, 2022

Opened a PR to use require.resolve #8003 Also, verified that it works in a webpack bundled Puppeteer version.

@OrKoN
Copy link
Collaborator

OrKoN commented Feb 14, 2022

That has now landed. I think it should work better than __dirname in Webpack environments. Let me know if it's not the case.

@OrKoN OrKoN closed this Feb 14, 2022
@codydaig
Copy link
Author

Thanks! Confirmed that it's fixed. (sorry for the delay, family stuff got in the way).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: __dirname points to root
3 participants