-
Notifications
You must be signed in to change notification settings - Fork 93
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 builds for node and browser #81
base: master
Are you sure you want to change the base?
Conversation
"type": "module", | ||
"main": "./lib/png-js.cjs", | ||
"module": "./lib/png-js.js", | ||
"browser": { |
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.
Instead of using non standard browser field, use nested conditions in exports field:
https://nodejs.org/api/packages.html#nested-conditions
IMO, for browser should have only import (es module)
This should be future proof.
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.
I think we might still need the browser field for backward compatibility though, eg for old tools that don't support exports. Otherwise we'll have to release this in a major version.
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.
Done! I also wanted to remove Buffer
usage in favor of Uint8Array (separately) if that sounds good for you guys. I think that should be breaking, but up to you 😄
package.json
Outdated
"import": "./lib/png-js.js", | ||
"require": "./lib/png-js.cjs" | ||
}, | ||
"default": "./lib/png-js.browser.js" |
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 need a "browser" path? If I understood node docs correctly node
takes precedence over default
, but it also mentions community conditions definitions which I guess are supported but not part of the standard
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.
No. Browser takes the default
Thanks for the review @blikblum ! when can we expect to have this merged? |
Need one more review |
Hi @devongovett ! Hope you are doing good.
I'd like to start using foliojs packages again in react-pdf. I gradually moved away from them due to several reasons, among them because node deps in foliojs repos. This includes pdfkit and png-js.
Here's my fork. This is the same node entrypoint here but bundled with rollup to generate node and browser entrypoints. Node ones are just like the existing ones. For browser though, we remove
fs
dependency and ignore methods that use it, and replacezlib
withbrowserify-zlib
.Not sure who's responsible of reviewing and publishing (I have merge rights here, but not publishing to npm) but this first step would be very helpful towards start unifying foliojs with react-pdf 😄