-
Notifications
You must be signed in to change notification settings - Fork 1
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
add CJS bundle highlight.js/compat
#3
base: esm-tests-more-work
Are you sure you want to change the base?
Conversation
@@ -31,6 +31,12 @@ async function buildNodeLanguage(language) { | |||
await rollupWrite(input, output); | |||
} | |||
|
|||
async function buildNodeBundle() { |
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.
Wouldn't buildNodeLanguage
also have to be updated/suplimented to build all the individual languages in CJS?
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.
It depends, we could decide that we supply only a bundle CJS file – or we can go the dual module package way and provide a CJS module for each language, but I thought you said that was not acceptable?
Can you not use
But still |
Conditional exports work whether or not you set a To test the conditional exports, the "right thing to do" is to use a self-reference to // root package.json
{
"name": "highlight.js",
"private": true,
"exports": {
".": {
"require": "./build/compat.cjs",
"import": "./build/lib/index.js"
},
"./lib/index": {
"require": "./build/compat.cjs",
"import": "./build/lib/index.js"
},
"./lib/languages/*": "./build/lib/languages/*.js"
}
} // build/package.json
{
"name": "highlight.js",
"type": "module",
"exports": {
".": {
"require": "./compat.cjs",
"import": "./lib/index.js"
},
"./lib/index": {
"require": "./compat.cjs",
"import": "./lib/index.js"
},
"./lib/languages/*": "./lib/languages/*.js"
}
} Hopefully that makes sense, let me know if that's not clear. |
Ok that works... but... Ugh, there has got to be some better way to test the built package asset independently of its source... Because this doesn't depend on the How is one supposed to properly test conditional requires of a fully built package in a CI environment, etc? I feel like we need a way to install the newly built package itself via npm and then run tests (or binary stubs) against that by name... am I thinking wrong here? |
Yep, that's probably necessary as an integration test to run in the CI. For local testing, having the root |
It seems you can do this with
|
Refs: #2 (comment)
Changes
Checklist
CHANGES.md