-
-
Notifications
You must be signed in to change notification settings - Fork 24
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
Throws an error if called from module without parent / which only called itself #18
Closed
Comments
We have the same issue in this GitHub Action: JulienKode/pull-request-name-linter-action#61 #19 can fix the issue I think |
This was referenced Oct 30, 2020
Closed
dummdidumm
added a commit
to sveltejs/language-tools
that referenced
this issue
Jun 24, 2024
No dependency inside svelte-check uses it anymore. If it creeps back in check if the dependency uses a version that fixed sindresorhus/import-fresh#18
dummdidumm
added a commit
to sveltejs/language-tools
that referenced
this issue
Jun 24, 2024
No dependency inside svelte-check uses it anymore. If it creeps back in check if the dependency uses a version that fixed sindresorhus/import-fresh#18
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have the situation where after bundling with Rollup I get an error when trying to resolve a config file through cosmiconfig and traced the error back to this package.
In my situation, after bundling, the bundled file is the top level module and
import-fresh
and the packages it depends on are also in that same file. The call to parent-module then returns undefined because the call stack only consists of the file itself. The next call to resolve-from on the other hand expects the filePath to be a string and throws. I think falling back to the moduleId-path or__filename
should be done instead.I can reproduce this if I place the code of
import-fresh
in the same file and invoke it like this:Reproduced on Windows 10 with node v14.5.0
I'm still not sure if I'm doing something wrong elsewhere because your package is used by so many other packages and noone has opened this issue yet.
The text was updated successfully, but these errors were encountered: