Skip to content

tsconfig: default esModuleInterop & allowSyntheticDefaultImports #243

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

Merged
merged 2 commits into from
Sep 27, 2022

Conversation

candrews
Copy link
Contributor

Enables projects that use this library to also have esModuleInterop set to false (which is the more strict options), improving ease of use.

@candrews candrews requested a review from a team as a code owner September 27, 2022 18:51
Enables projects that use this library to also have esModuleInterop set to false (which is the more strict options), improving ease of use.

Signed-off-by: Craig Andrews <[email protected]>
@candrews candrews force-pushed the esModuleInterop-false branch from 5b92635 to 1b04911 Compare September 27, 2022 18:52
@jkowalleck jkowalleck changed the title Set typescript config esModuleInterop to false tsconfig: default esModuleInterop & allowSyntheticDefaultImports Sep 27, 2022
@jkowalleck
Copy link
Member

I modified the original change request from @candrews so that now the tsconfig default value is used,
which is the same as he intended to use.
This way we have less customs and have the desired outcome.

@jkowalleck jkowalleck merged commit 4c47aec into CycloneDX:main Sep 27, 2022
@jkowalleck
Copy link
Member

jkowalleck commented Sep 27, 2022

thanks for the improvement, @candrews .
looking forward to having it released in the next days.

@jkowalleck
Copy link
Member

jkowalleck commented Mar 15, 2023

@candrews

I got the impression, that you are running your own webpack process on the source code of this project.
If so: Could you elaborate why you are re-compiling this library downstream ? It is already in a compiled version available, right?

Or is this not because of recompiling but usage of a TypeScript code that uses import foo from 'bar'??

Some background: I want to incorporate a better SPDX license expression validation process. Therefore, I wanted to utilize a module which requires esModuleInterop to be enabled, again.

@jkowalleck
Copy link
Member

jkowalleck commented Mar 15, 2023

Caused by #271

Might need to reopen this, to get https://www.npmjs.com/package/spdx-expression-parse in
This package exports like module.exports = function () {}
which requires the usage like import foo from 'bar'.
And this requires to enable esModuleInterop to be enabled.

Having esModuleInterop not enabled was the purpose of this PR.

So the new code would revert this PR. :-/
any advice, @candrews

@jkowalleck jkowalleck mentioned this pull request Mar 15, 2023
@candrews
Copy link
Contributor Author

Could you elaborate why you are re-compiling this library downstream ? It is already in a compiled version available, right?

I'm using it in my fork of Snyk CLI that generates CycloneDX SBOMs: https://github.com/candrews/snyk-cli

Here's the PR to the Snyk project which shows exactly the changes in my fork: snyk/cli#3983

This library is imported using:
import * as cdx from '@cyclonedx/cyclonedx-library';

@jkowalleck
Copy link
Member

Ah, I remember. Thanks.

So all good, as long as the type declarations consumed downstream do not require esModuleInterop nor allowSyntheticDefaultImports?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants