-
Notifications
You must be signed in to change notification settings - Fork 168
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
feat: dual module export #607
feat: dual module export #607
Conversation
Missed two file extenstions on the test suite used for type checking. Updated and committed b74fd58 |
declare module 'deep-copy' { | ||
declare function dcopy<T>(arg: T): T | ||
export default dcopy | ||
} |
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 wondering,
why do we need this? deep-copy comes out of the box with type defs.
Not sure what I'm missing 🙏
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 type defs don't support ES modules. The export a function, not a module. ES modules require a module declaration for modules to be reference correctly.
The type def shipped looks like this
declare function dcopy<T>(arg: T): T
export default dcopy
with no module declaration
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.
Oh, gotcha!
Hey @antstanley, You're awesome. LGTM! |
Yay! I've recently gone on a mission to get all the packages I use to support dual modules so I can use ESM in Lambda. Merging this saves me over a 1MB in my bundle size for one of my functions Thank you! |
this is now available in v0.9.0 :) |
This PR adds dual CommonJS and ES Module support to DynamoDB Toolbox.
Issue it resolves: #606
The changes include the following
package.json
to includeexports
property to define location to be used for ES importspackage.json
to set default module type tomodule
Create a
tsconfig.esm.json
file with ES module specify TypeScript settingsRename
tsconfig.build.json
totsconfig.cjs.json
and add CommonJS setting for TypeScriptUpdate root
tsconfig.json
to use ES modules by defaultUpdate all
.ts
files to use explicit.js
imports in accordance with the ES Module spec and Node implementation. Reference https://www.totaltypescript.com/relative-import-paths-need-explicit-file-extensions-in-ecmascript-importsRename
jest.config.js
tojest.config.cjs
to explicitly set it to a CommonJS module as the package default is nowmodule
Update
ts-jest
config injest.config.cjs
touseESM: true
and other ES module required configUpdate all test files to use explicit
.js
imports as required by ES module spec and Node implementationAdd module declaration
deep-copy.d.ts
for thedeep-copy
module used byEntity
, as it's existing declaration is not sufficient for ES modulesApologies for the size of the PR. Unfortunately due to ES modules requiring explicit import of files by
.js
extensions I had to touch almost every file, but I only touched them gently.The tests run and pass. I've also shipped a version of this to
@antstanley/dynamodb-toolbox
if you want to run it yourself and validate behaviour.Bundling this version now enables me to use ES modules with DynamoDB Toolbox in my Lambda functions without bundling the AWS SDK v3.
One side effect I've noticed is the ES module version of DynamoDB Toolbox bundles more efficiently, dropping around 30Kb from my specific bundle.