-
Notifications
You must be signed in to change notification settings - Fork 3
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
feat: esm and cjs exports #427
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gonna hold off approving till you mark this as "Ready for review", but generally this looks good to me. Left some comments/questions below.
@@ -1,4 +1,4 @@ | |||
const fetchHAR = require('.').default; | |||
const fetchHAR = require('.'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this change to the export/import pattern break things for CJS users? Or will it also work from .default
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nah the default
is no longer required — this is likely going to be a breaking change! the default
thing was actually a bit of a code smell since we probably weren't exporting types properly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worth calling out in the changelog (or in the commit message)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep will do in the GitHub release!
Co-Authored-By: Ilias Tsangaris <[email protected]>
that way we can use the conditional require syntax!
"polyfills": [ | ||
"fetch", | ||
"Headers", | ||
"Request" | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these weren't necessary!
(server) implies the existence of (client), which isn't a thing 😔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
"undici": "^5.24.0" | ||
"@readme/data-urls": "^3.0.0", | ||
"@types/har-format": "^1.2.13", | ||
"undici": "^5.25.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to bring this in if we're just using whatever native fetch() is present in the environment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm we'll have to ask jon but i believe we still need it for node environments (see this comment and below):
Lines 16 to 25 in 9e0360d
if (!globalThis.File) { | |
try { | |
// Node's native `fetch` implementation unfortunately does not make this API global so we need | |
// to pull it in if we don't have it. | |
// eslint-disable-next-line @typescript-eslint/no-var-requires | |
globalThis.File = require('undici').File; | |
} catch (e) { | |
throw new Error('The File API is required for this library. https://developer.mozilla.org/en-US/docs/Web/API/File'); | |
} | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kanadgupta @domharrington We could move this to optionalDependencies
but yeah this is only really needed for server environments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Annoyingly, File
only became a global in Node v20: https://nodejs.org/docs/latest/api/globals.html#class-file otherwise we could just use that.
@@ -5,6 +5,7 @@ import fs from 'node:fs/promises'; | |||
import DatauriParser from 'datauri/parser'; | |||
import express from 'express'; | |||
import multer from 'multer'; | |||
// @ts-expect-error this file is ESM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kanadgupta Is this still needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sick
🧰 Changes
This PR refactors this codebase to support both ESM and CJS exports. I was originally blocked in #426 (comment) — turns out the issue was the
treeshaking
flag. Removing that (and separating out the type exports intotypes.ts
) fixes the issue!This PR also does a little bit of housekeeping:
🧬 QA & Testing
Before/after for Are The Types Wrong
If you check out this repo and run the following commands, they should work as expected: