Behavior when loaded with node is confusing
See original GitHub issueIf someone tries to require the module from Node (like in a REPL below)
$ node
> require('fitty')
{ default: undefined }
> require('fitty').default
undefined
> require('fitty').default()
TypeError: require(...).default is not a function
It isn’t clear what went wrong. I’d really recommend throwing an error or at least logging to stderr when this is attempted, at this point in your code:
// no window, early exit
if (!w) {
// throw or log error here please
return;
}
It was really confusing to me when, separately, I wasn’t able to get the import working as expected.
Oh, and thanks for writing fitty!
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (2 by maintainers)
Top Results From Across the Web
Confusing behaviour of Cheerio (Node.js) - Stack Overflow
Confusing behaviour of Cheerio (Node.js) · Likely because items are asynchronously loaded. try using setTimeout and let them get rendered. – ...
Read more >Top 10 Most Common Node.js Developer Mistakes - Toptal
Mistake #1: Blocking the event loop However, in a Node. js server instance trying to serve thousands of users at a time, such...
Read more >node --loader treats entrypoint as ESM when should ... - GitHub
When --loader is passed, node always tries to load entrypoint scripts as ESM, ignoring that package.json wants the file to be treated as...
Read more >Node.js v19.3.0 Documentation
Building; Linking to libraries included with Node.js; Loading addons using require() ... Bugs or behavior changes may surprise users when Experimental API ...
Read more >Really confused about nodeJS and why it's important and how ...
Basically, when you type in a website name, The server sends the HTML, CSS, and JavaScript code to your browser. To understand the...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@searls happy to merge any pull requests that fix this
The same functions to be there, regardless of whether they worked. For example, I’d bail at the last possible moment, and not at require-time. Maybe a user will require
jsdom
right afterward only to find fitty is{default: undefined}
instead of{default: function thisWillBlowUpWithoutADom(){}}
.