Add cjs build alongside esm #51
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Still seem to be issues for the integration I'm testing. One to pick up with more motivation in the New Year!
This seems to be the simplest way to get ESM and CJS without throwing up issues due to the intel hex library. It's more similar to microbit-fs.
Deploying microbit-connection with
|
| Latest commit: |
f572847
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://81730a3f.microbit-connection.pages.dev |
| Branch Preview URL: | https://commonjs.microbit-connection.pages.dev |
microbit-grace
pushed a commit
to microbit-foundation/microbit-fs
that referenced
this pull request
Jan 29, 2025
- Remove DeviceVersion exported const enum in favour of a union (breaking change due for code like `DeviceVersion.V1` but not expected to have wide impact. The values are unchanged.).
- Remove UMD build. Stop offering a browser oriented bundle.
- If we know of any real-world script-tag-only users then I'm open to reinstating this but I'm really dubious it's worth it.
- CJS now uses dependencies rather than bundles to aid use alongside microbit-connection (avoiding duplicating nrf-intel-hex in that scenario).
- Fix ES module so it works with Node's ES module support (exports in package.json, .js file extensions on imports)
- Emit more modern JavaScript (ES2021, consistent with microbit-connection).
- Consolidate documentation into typedoc
- Move the markdown content into typedoc's build so we don't have separation and simplify
- Drop the unmaintained theme
- Move to GHA publishing it to GitHub pages
- This is now simple enough I can imaging rolling it out to other libraries
- Update linting, TypeScript etc.
- Intending to port most of this to typescript-library-starter, but hopefully using NodeNext there.
- Stuck on "node10" TypeScript bundleResolution for the same reason as microbit-foundation/microbit-connection#51
Other than DeviceVersion there's no code-level behaviour change but it's likely also a breaking change due to the ES2020 emit and the packaging changes so bumping version to 0.10.0. I think it should generally be easier to consume in modern projects while still working in CJS/webpack 5 type setups.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
type: modulein this package causes the ESM build to fail with errors about MemoryMap being a namespace not a type. I think this is what theMemoryMap.defaultcludges we've had to remove were addressing.type: moduleand the obviousexportsintonrf-intel-hexthen it builds cleanly so I think that's the best route forward but we'll need this in the interim.We've verified that the built package can be consumed by our Vite builds, Vitest tests (which use Node) and a Webpack 5 project that mirrors code.org's configuration.
Because this cjs build depends on nrf-intel-hex we're also going to modernise microbit-fs to have a CJS build that doesn't bundle nrf-intel-hex.