ES Modules #295
ES Modules #295
Conversation
Blank binary file was not getting serialized as { type: "Buffer", data: [] }
because read(file) was returning a string instead of Buffer.
Webpack 4 cannot parse module containing optional chaining operator. See https://stackoverflow.com/questions/59972341/how-to-make-webpack-accept-optional-chaining-without-babel
Recent versions of node upgraded to OpenSSL 3.0, which deprecated some older crypto hashing algorithms including md4. Webpack 4 hard codes the use of md4 ins some places, so we have to set this flag until we can upgrade Webpack.
Browser tests were failing as polyfill.js was loading a node package in a browser context.
This was when the --openssl-legacy-provider option was introduced. Prior versions of node do not recognize this option.
Browser tests are failing in the CI environment with: chokidar@3: Error: Cannot find module 'chokidar' Don't know why but this thread might be relevant: facebook/create-react-app#10811
Preserve backwards compatibility
Fixes “require() of ES Module …/config.js not supported” error
The current configuration of karma uses Webpack 4, which can't parse modules with top-level await.
Karma configuration needs to upgrade to Webpack 5 in order to use import.meta.url
jamesmoschou
force-pushed
the
esmodules
branch
from
e7ed50a
to
f571f0a
Compare
This reverts commit f571f0a.
…lt property
Without this hack, you would have to do this:
const $RefParser = require("@apidevtools/json-schema-ref-parser).default;
Now you can do this:
const $RefParser = require("@apidevtools/json-schema-ref-parser);
|
Hey @philsturgeon this now implements dual CommonJS/ES module support and is ready to merge. The one thing to call out is that the minimum Node version is now 17, not 14 according to the engines property in package.json. Though it only matters for running tests and it should still work in 14. |
|
I’m ok increasing versions under those terms as we’re aiming for EAM in a major anyway. Now we’ve merged the other PR can we update and see if this is good to go? Thank you so much for your support. |
Pull Request Test Coverage Report for Build 3897768158
💛 - Coveralls |
|
Yep, looks like all checks have passed |
|
oh there's conflicts... |
|
ok fixed |
|
Thank you @jamesmoschou! This is a great update. I had to manually release it because semantic-release has gone off the rails, but hopefully thats working ok. Would you be up for maintaining this package because I am working in the woods 90% of the time now and don't want to be stressing about this when I get back to a computer. I'm also asking if readmeio#64 can take over, which may just involve merging some of the recent changes and me pointing this package to them. |
|
Hey @philsturgeon I can help maintain this package. Though I mean maintain in the literal sense, I wouldn't be developing any new feature requests. Looks like the node engine breaking change snuck in to v9.* version instead of v10. I can update this is you set up the permission :) |
|
Sorry, referencing my comment here. It looks like this is the one that broke our project. |
|
@coffeebe4code fixed in 9.1.2. |
(This PR builds off #294)
Convert the project to ES Modules and implements dual CommonJS/ES module exports.