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

Show the original error message when a browser provider can't be loaded #4522

Closed
AndreyBelym opened this issue Nov 26, 2019 · 1 comment · Fixed by #4690
Closed

Show the original error message when a browser provider can't be loaded #4522

AndreyBelym opened this issue Nov 26, 2019 · 1 comment · Fixed by #4690
Labels
AREA: server HELP WANTED STATE: Auto-locked An issue has been automatically locked by the Lock bot. SYSTEM: browser natives TYPE: enhancement The accepted proposal for future implementation.

Comments

@AndreyBelym
Copy link
Contributor

What is your Test Scenario?

Try to use a browser provider that has a missing third-party dependency.

What are you suggesting?

Show the original Node.js require error that references the missing module when requiring a browser provider fails.

What alternatives have you considered?

Run node -e "require.resolve('testcafe-browser-provider-PROVIDER')" in the TestCafe installation directory.

Additional context

DevExpress/testcafe-browser-provider-browserstack#71

@AndreyBelym AndreyBelym added TYPE: enhancement The accepted proposal for future implementation. SYSTEM: browser natives AREA: server labels Nov 26, 2019
danwenzel pushed a commit to danwenzel/testcafe that referenced this issue Jan 23, 2020
Fixes DevExpress#4522 and DevExpress#4673.

First uses `require.resolve`, which will only throw an error if the provider module itself doesn't exist. If it does exist, we then use `require` to load the module, not catching errors. That way, any errors caused by a 3rd party dependency will show up.
danwenzel pushed a commit to danwenzel/testcafe that referenced this issue Jan 23, 2020
Fixes DevExpress#4522 and DevExpress#4673.

First uses `require.resolve`, which will only throw an error if the provider module itself doesn't exist. If it does exist, we then use `require` to load the module, not catching errors. That way, any errors caused by a 3rd party dependency will show up.
miherlosev pushed a commit to danwenzel/testcafe that referenced this issue Mar 19, 2020
Fixes DevExpress#4522 and DevExpress#4673.

First uses `require.resolve`, which will only throw an error if the provider module itself doesn't exist. If it does exist, we then use `require` to load the module, not catching errors. That way, any errors caused by a 3rd party dependency will show up.
miherlosev added a commit that referenced this issue Mar 23, 2020
* Only catch error if provider module itself does not exist

Fixes #4522 and #4673.

First uses `require.resolve`, which will only throw an error if the provider module itself doesn't exist. If it does exist, we then use `require` to load the module, not catching errors. That way, any errors caused by a 3rd party dependency will show up.

* add test

* update device for browserstack

* revert browserstack device version

Co-authored-by: miherlosev <[email protected]>
@lock
Copy link

lock bot commented Apr 2, 2020

This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests. We recommend you ask TestCafe API, usage and configuration inquiries on StackOverflow.

@lock lock bot added the STATE: Auto-locked An issue has been automatically locked by the Lock bot. label Apr 2, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Apr 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
AREA: server HELP WANTED STATE: Auto-locked An issue has been automatically locked by the Lock bot. SYSTEM: browser natives TYPE: enhancement The accepted proposal for future implementation.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant