-
Notifications
You must be signed in to change notification settings - Fork 467
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
Provide ESM build #67
Comments
Hello, you can take a look at this package. It is a copy for import SparkMD5, { md5, md5Sum } from 'https://unpkg.com/[email protected]/dist/md5.js' |
I have the same request as @NicBright. |
the repo is here, and just add an |
thanks ! |
Just to point out that there is fork of js-spark-md5 that just changes what needs to be changed to make it ESM: The diff is actually minimal: master...scx567888:js-spark-md5-es:master You don't even have to change your imports if you alias the package in your package.json: "dependencies": {
"spark-md5": "npm:[email protected]"
},
"devDependencies": {
"@types/spark-md5": "3.0.4"
} I use PNPM, but I figure aliasing is the same in NPM and Yarn, or at least similiar. |
Hi there
I wonder whether it would be possible for you to provide an ESM compatible build ... ? Why? It's all about the shift of going from
require()
toimport / export
style syntax ...My special use case is this: I'm migrating our code base's unit tests (Jest) to ESM modules, see https://jestjs.io/docs/ecmascript-modules
For this to work, however, the packages need to conform to new ESM modules standards. For example, Jest will fail when it encounters old CommonJS style
require()
calls. In the case ofspark-md5
, it is not even possible (for me) to add it to Jest'stransformIgnorePatterns
(and have it be re-compiled) because (I'm not an UMD expert) it seems to me that the generated UMD file (spark-md5.js
) is malformed. So for now I have to copy the whole source code ofspark-md5
directly into my code base (in ESM module compatible way) as a workaround.The new
exports
property in package.json helps with providing builds delivering modern ESM modules. Being backwards-compatible with old Node.js versions at the same time is easy because old Node.js versions will ignore theexports
property and keep referring to package.json'smain
property instead (so you can still provide a CommonJS build and point to it viamain
property). If you don't know the newexports
property, I recommend a short read of the following resources:Best Regards,
Nicolas
The text was updated successfully, but these errors were encountered: