Skip to content
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

Corrected type definitions. Fixes #56 #57

Merged
merged 4 commits into from
Jul 1, 2019

Conversation

JamesMessinger
Copy link
Contributor

This PR fixes #56 by correcting the TypeScript definitions to properly reflect the fact that Unified exports a CommonJS module rather than an ESM module.

  • Replaced incorrect export default syntax with export =
  • Wrapped all the TypeScript type definitions in a namespace

This PR corrects the TypeScript definitions to properly reflect the fact that Unified exports a CommonJS module rather than an ESM module.

* Replaced incorrect `export default`  syntax with `export =`
* Wrapped all the TypeScript type definitions in a namespace
Copy link
Member

@ChristianMurphy ChristianMurphy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a test case to types/unified-tests.ts to verify the commonjs style import works as expected?
As it stands now, the tests passed before and continue to pass, and building the code worked in wbepack before and works with this change.
Without a test case, there is not way prevent this issue from popping up again.

@@ -6,7 +6,6 @@
"noImplicitThis": true,
"strictNullChecks": true,
"strictFunctionTypes": true,
"esModuleInterop": true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would documenting that esModuleInterop should be enabled, resolve this issue without reverting the typings refactor?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The esModuleInterop setting should only be used in end applications, not libraries. It's a way for app developers to treat CommonJS modules as though they were ESM modules, but it results in lots of little helper functions being injected into the code to handle the mapping between the two module formats. App developers should be able to opt-in or opt-out of that behavior, depending on whether they're okay with the trade-off.

@ChristianMurphy
Copy link
Member

/cc @Rokt33r

Copy link
Member

@Rokt33r Rokt33r left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me. Thanks @JamesMessinger !

@ChristianMurphy ChristianMurphy merged commit 3f16529 into unifiedjs:master Jul 1, 2019
@wooorm
Copy link
Member

wooorm commented Jul 1, 2019

How should this be released?

@Rokt33r
Copy link
Member

Rokt33r commented Jul 1, 2019

@wooorm Did you mean the version? If so, we could publish as a patch version, like 8.0.1.

@wooorm
Copy link
Member

wooorm commented Jul 1, 2019

Yeah, I meant version. So a patch is fine? Alright!

wooorm pushed a commit to remarkjs/remark that referenced this pull request Jul 20, 2019
Related to unifiedjs/unified#53.
Related to unifiedjs/unified#54.
Related to unifiedjs/unified#56.
Related to unifiedjs/unified#57.
Related to unifiedjs/unified#58.
Related to unifiedjs/unified#59.
Related to unifiedjs/unified#60.
Related to unifiedjs/unified#61.
Related to unifiedjs/unified#62.
Related to unifiedjs/unified#63.
Related to unifiedjs/unified#64.
Related to #426.

Reviewed-by: Titus Wormer <tituswormer@gmail.com>
Reviewed-by: Junyoung Choi <fluke8259@gmail.com>
Reviewed-by: Christian Murphy <christian.murphy.42@gmail.com>

Co-authored-by: Junyoung Choi <fluke8259@gmail.com>
Co-authored-by: Christian Murphy <christian.murphy.42@gmail.com>
@wooorm wooorm added ☂️ area/types This affects typings ⛵️ status/released 🐛 type/bug This is a problem 👶 semver/patch This is a backwards-compatible fix labels Aug 10, 2019
@wooorm wooorm added the 💪 phase/solved Post is done label May 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
☂️ area/types This affects typings 💪 phase/solved Post is done 👶 semver/patch This is a backwards-compatible fix 🐛 type/bug This is a problem
Development

Successfully merging this pull request may close these issues.

Broken TypeScript definitions
5 participants