Merged
Conversation
Supporting ES Modules is harder than first thought!
jacobwinch
approved these changes
Mar 31, 2021
Contributor
jacobwinch
left a comment
There was a problem hiding this comment.
Thanks for taking the time to explain this in detail 👍
Member
Author
Module formats in Node are complicated! I hope my explanation is correct 😬 ! |
Contributor
|
🎉 This PR is included in version 6.2.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This file contains hidden or 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
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.
What does this change?
TL;DR Publishing
@guardian/cdkin ESM format is tricky, it is easiest to stay on CommonJS.In #365, we changed the output format to ES Modules. This was after #356 which bumped
read-pkg-upto v8.0.0.Looking at
read-pkg-up's release notes for v8.0.0 the package has changed to ESM only and consuming projects need to:More information can be found here.
#365 incorrectly did option 1 as
"type": "module"was not added topackage.json. However, even with that change, it is pretty difficult for consumers of@guardian/cdkto use an ESM release as required tooling such as ts-node (see also this), ESLint and Jest have varying support.This PR does option 3. That is, publishing
@guardian/cdkin ESM format is tricky, it is easiest to stay on CommonJS. We'll have to stay on v7.0.1 ofread-pkg-upto achieve this; v8.0.0 doesn't bring any new features or fixes, so this is safe.Furthermore, after a couple of hours, I couldn't get option 2 to work, even though top level await is supported. We can experiment later.
It's worth noting that #367 plans to introduce an integration test to this repository, which should make experimenting with various module formats with more confidence. Currently, this test will define an empty
GuStackand attempt to synth it.Lastly, although #365 suggests the change was tested locally, I suspect it was fluke that it worked.
Does this change require changes to existing projects or CDK CLI?
No.
How to test
n/a - we're getting back into the same state as we were before #356 and
@guardian/cdkv6.0.1.How can we measure success?
We publish a usable package again!
Have we considered potential risks?
n/a