-
-
Notifications
You must be signed in to change notification settings - Fork 17
feat!: switch to ESM and native TypeScript type-stripping #166
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
base: main
Are you sure you want to change the base?
Changes from all commits
6e4ef80
af1000c
6c2b2e3
a2c6379
2ef41ea
7b9ea16
e4fe455
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,8 +2,15 @@ | |
| "name": "@fastify/flash", | ||
| "version": "6.0.5", | ||
| "description": "Flash message plugin for fastify.", | ||
| "main": "./lib", | ||
| "type": "commonjs", | ||
| "type": "module", | ||
| "main": "./lib/index.js", | ||
| "types": "./lib/index.d.ts", | ||
| "exports": { | ||
| ".": { | ||
| "types": "./lib/index.d.ts", | ||
| "default": "./lib/index.js" | ||
| } | ||
| }, | ||
| "scripts": { | ||
| "build": "npm run clean-build && npm run lint && tsc -p ./tsconfig.build.json", | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this building correctly for release? is tsconfig.build.json correct?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, verified locally on Node 24.18.0. Commands to reproduce: Output:
|
||
| "clean-build": "rimraf ./lib && mkdir lib", | ||
|
|
@@ -57,7 +64,7 @@ | |
| "devDependencies": { | ||
| "@fastify/secure-session": "^8.0.0", | ||
| "@types/node": "^26.0.0", | ||
| "borp": "^0.21.0", | ||
| "borp": "^1.0.0", | ||
| "eslint": "^9.35.0", | ||
| "fastify": "^5.0.0", | ||
| "neostandard": "^0.13.0", | ||
|
|
@@ -72,5 +79,8 @@ | |
| ], | ||
| "publishConfig": { | ||
| "access": "public" | ||
| }, | ||
| "engines": { | ||
| "node": ">=20.19.0 <21 || >=22.12.0" | ||
| } | ||
| } | ||

There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to confirm, you mean
main/typesare redundant now that exports is present, right? 😅There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why using
exportswhen you only have single entrypoint?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only advantage, now that I think about it is: "encapsulation".
The
exportsfield explicitly defines the package's public interface. Without it, nothing prevents a user from runningrequire('@fastify/flash/lib/flash.js')and depending on an internal file. Withexports, that import throwsERR_PACKAGE_PATH_NOT_EXPORTED, so we're free to restructure the internals oflib/later without it being a breaking change.That said, we could also just drop it and keep this instead:
Happy to go either way, let me know which you'd prefer 😉