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

Change relative import to extensioned variations for Node16 and NodeNext #6399

Merged
merged 2 commits into from
Aug 28, 2023

Conversation

tnorling
Copy link
Collaborator

Addresses Node 16 and NodeNext moduleResolution types

Thanks @datner for the PR!

…ext type support (#6380)

- chore(msal-node): add $schema props for schema validation
- test(msal-node): add support for .js extension import
- build(msal-node): remove redundant pass
- feat(msal-node): change all relative imports to .js

I've made meaningful commits, so I recommend you review them instead of
all the files at once.

The other solutions are:
1. to manually transform d.ts files after the build, which is a great
way to introduce both complexity and brittleness to the project
2. use self-imports, allowing many entry-points `import { Configuration
} from "@azure/msal-node/config/Configuration"` letting typescript and
node to each resolve it in the way they understand. But this is a
massive design-shift
3. using package.json `"imports"` entry. Just changing one problem for
another, not a real solution and doesn't scale
4. emitting 2 `d.ts` versions, `d.mts` and `d.cts`. Thats possible but
just.. redundant?

There are a few oddities, like the meme extensions importing only within
their meme domain, but `d.ts` referencing non-existent `.js` files.
Which is fine because it will just direct _Typescript_ to the correct
`d.ts` and there isn't an interface difference between cjs and esm. Also
`jest` had to be adjusted since it never got the memo that 3 LTS
versions ago nodejs started supporting and advocating for `.js`
extensions. If we ditch one of the meme extensions then this would be
visually less scary, though it should be just as safe as it is now.

closes #6377

personal note:
Please don't bike-shed this pr for months, yes it would probably break
node versions before 12 but come on. [even 16 is literally days away
from deprecation](https://github.com/nodejs/release#release-schedule),
it would be absolutely unreasonable.. This is over all a small change
with a visually large foot print
@codecov-commenter
Copy link

codecov-commenter commented Aug 26, 2023

Codecov Report

Merging #6399 (78eddae) into dev (81d34b4) will decrease coverage by 4.98%.
Report is 274 commits behind head on dev.
The diff coverage is n/a.

Flag Coverage Δ
msal-angular ?
msal-browser ?
msal-common ?
msal-core ?
msal-node 80.01% <ø> (-3.38%) ⬇️
msal-node-extensions ?
msal-react ?
node-token-validation ?

see 233 files with indirect coverage changes

@datner
Copy link
Contributor

datner commented Aug 26, 2023

🎉

@tnorling tnorling merged commit b4924fa into dev Aug 28, 2023
28 of 29 checks passed
@tnorling tnorling deleted the fix-esm-exports branch August 28, 2023 19:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
msal-node Related to msal-node package
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Types are broken for moduleResolution: Node16 and NodeNext
5 participants