-
Notifications
You must be signed in to change notification settings - Fork 213
Output ESM for all packages #736
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
Conversation
* main: [ci] release (#721) @tus/s3-store: fix unhandled promise rejection (#728) Bump @aws-sdk/client-s3 from 3.717.0 to 3.758.0 (#733) Bump @types/node from 22.10.1 to 22.13.7 (#734) Bump typescript from 5.6.2 to 5.8.2 (#731) @tus/azure-store: fix non-ASCII characters error on metadata (#725) Fix package-lock.json
🦋 Changeset detectedLatest commit: 8c11b8d The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughThis pull request introduces significant dependency upgrades and transitions the codebase to an ESM-only architecture. Several packages (such as Changes
Possibly related PRs
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Removed dependencies detected. Learn more about Socket for GitHub ↗︎ 🚮 Removed packages: npm/[email protected] |
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.
Actionable comments posted: 0
🧹 Nitpick comments (5)
packages/server/src/test/Locker.test.ts (2)
28-29
: Assertion Message Consistency: Correct Variable Reference
The error message in the assertion on line 29 referencescancel.callCount
instead ofcancel2.callCount
, which can lead to confusion during debugging. Please update the error message to use the correct variable.
118-119
: Consistent Assertion Messaging: Correct Variable in Error Message
Similarly, the assertion on line 119 incorrectly referencescancel.callCount
in its error message while verifyingcancel2.callCount
. Fixing this will improve clarity in test failure messages.packages/gcs-store/package.json (1)
13-16
: Files Array Adjustments
Including"dist"
and"src"
while excluding test files using"!test*"
is appropriate for ensuring that only the necessary files are packaged. Please verify that the removal of"README.md"
and"LICENSE"
from the"files"
array is intentional for this package distribution.packages/utils/package.json (1)
13-16
: Revised Files Inclusion
Updating the"files"
array to include"dist"
and"src"
while excluding test files via"!test*"
is in line with the new build and packaging strategy. Double-check that removing"README.md"
and"LICENSE"
from the package does not affect documentation or licensing needs for end users.packages/azure-store/package.json (1)
12-16
: Optimized Files Array
The"files"
array now includes"dist"
and"src"
and excludes test files using"!test*"
. This modification streamlines the published content. As with the other packages, ensure that omitting"README.md"
and"LICENSE"
is an intentional change for your package distribution.
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.json
is excluded by!**/package-lock.json
📒 Files selected for processing (64)
.changeset/tricky-paws-hear.md
(1 hunks)biome.json
(1 hunks)package.json
(1 hunks)packages/azure-store/package.json
(1 hunks)packages/azure-store/src/test/index.ts
(1 hunks)packages/azure-store/tsconfig.build.json
(0 hunks)packages/azure-store/tsconfig.json
(1 hunks)packages/file-store/package.json
(1 hunks)packages/file-store/src/index.ts
(1 hunks)packages/file-store/src/test/index.ts
(1 hunks)packages/file-store/tsconfig.build.json
(0 hunks)packages/file-store/tsconfig.json
(1 hunks)packages/gcs-store/package.json
(1 hunks)packages/gcs-store/src/test/index.ts
(1 hunks)packages/gcs-store/tsconfig.build.json
(0 hunks)packages/gcs-store/tsconfig.json
(1 hunks)packages/s3-store/package.json
(1 hunks)packages/s3-store/src/test/index.ts
(1 hunks)packages/s3-store/tsconfig.build.json
(0 hunks)packages/s3-store/tsconfig.json
(1 hunks)packages/server/package.json
(2 hunks)packages/server/src/handlers/BaseHandler.ts
(1 hunks)packages/server/src/handlers/DeleteHandler.ts
(1 hunks)packages/server/src/handlers/GetHandler.ts
(1 hunks)packages/server/src/handlers/HeadHandler.ts
(1 hunks)packages/server/src/handlers/OptionsHandler.ts
(1 hunks)packages/server/src/handlers/PatchHandler.ts
(1 hunks)packages/server/src/handlers/PostHandler.ts
(2 hunks)packages/server/src/index.ts
(1 hunks)packages/server/src/lockers/index.ts
(1 hunks)packages/server/src/server.ts
(2 hunks)packages/server/src/test/BaseHandler.test.ts
(1 hunks)packages/server/src/test/DeleteHandler.test.ts
(1 hunks)packages/server/src/test/GetHandler.test.ts
(1 hunks)packages/server/src/test/HeadHandler.test.ts
(1 hunks)packages/server/src/test/HeaderValidator.test.ts
(1 hunks)packages/server/src/test/Locker.test.ts
(1 hunks)packages/server/src/test/OptionsHandler.test.ts
(1 hunks)packages/server/src/test/PatchHandler.test.ts
(1 hunks)packages/server/src/test/PostHandler.test.ts
(1 hunks)packages/server/src/test/Server.test.ts
(1 hunks)packages/server/tsconfig.build.json
(0 hunks)packages/server/tsconfig.json
(1 hunks)packages/utils/package.json
(1 hunks)packages/utils/src/index.ts
(1 hunks)packages/utils/src/kvstores/FileKvStore.ts
(1 hunks)packages/utils/src/kvstores/IoRedisKvStore.ts
(1 hunks)packages/utils/src/kvstores/MemoryKvStore.ts
(1 hunks)packages/utils/src/kvstores/RedisKvStore.ts
(1 hunks)packages/utils/src/kvstores/Types.ts
(1 hunks)packages/utils/src/kvstores/index.ts
(1 hunks)packages/utils/src/models/DataStore.ts
(1 hunks)packages/utils/src/models/Metadata.ts
(1 hunks)packages/utils/src/models/StreamLimiter.ts
(1 hunks)packages/utils/src/models/index.ts
(1 hunks)packages/utils/src/test/Metadata.test.ts
(1 hunks)packages/utils/src/test/StreamSplitter.test.ts
(1 hunks)packages/utils/src/test/Uid.test.ts
(1 hunks)packages/utils/src/test/Upload.test.ts
(1 hunks)packages/utils/src/test/stores.ts
(1 hunks)packages/utils/tsconfig.build.json
(0 hunks)packages/utils/tsconfig.json
(1 hunks)test/package.json
(2 hunks)test/tsconfig.json
(1 hunks)
💤 Files with no reviewable changes (6)
- packages/file-store/tsconfig.build.json
- packages/s3-store/tsconfig.build.json
- packages/server/tsconfig.build.json
- packages/gcs-store/tsconfig.build.json
- packages/azure-store/tsconfig.build.json
- packages/utils/tsconfig.build.json
🔇 Additional comments (90)
biome.json (1)
2-2
: Schema version updated appropriately.The
biome.json
schema version has been updated from 1.8.3 to 1.9.0, which aligns with the dependency update in package.json (Biome is now at version 1.9.4).packages/utils/src/models/StreamLimiter.ts (1)
2-2
: Import path correctly updated for ESM compatibility.The import statement now includes the
.js
extension, which is required for ESM modules. This change is consistent with the PR objective of enabling ECMAScript Module output.package.json (1)
4-7
: Workspaces formatting improved for readability.The workspaces field has been reformatted from a single-line array to a multi-line format, improving readability without changing functionality. This is a good formatting change.
packages/server/src/lockers/index.ts (1)
1-1
: Export path correctly updated with .js extension for ESM compatibility.The export statement now includes the
.js
extension which is required for ESM. This change aligns with the PR's goal of enabling ECMAScript Module output.packages/utils/tsconfig.json (2)
4-4
: ESM Configuration Alignment: Update "include" Directive
Changing from using an "exclude" property to explicitly including"src"
ensures that only the intended source files are compiled. This aligns with the project’s unified build approach.
6-7
: Clear Output Definitions: Added "rootDir" and "outDir" Options
Specifying"rootDir": "src"
and"outDir": "dist"
provides a clear separation between source and compiled files, which is especially important now that the project is migrating its output for ESM.test/tsconfig.json (2)
3-8
: Consistent References: Updated Package TS Config Paths
Updating the"references"
array to point to the package-leveltsconfig.json
files (instead of now-removed build configs) maintains consistency across packages and streamlines the build process under the new ESM strategy.
11-16
: Unified Compiler Options: Correct "include", "rootDir", and "outDir"
Switching to an"include": ["src"]
directive and explicitly defining"rootDir"
and"outDir"
aligns this configuration with the rest of the project, ensuring a consistent compilation context across packages.packages/server/src/handlers/OptionsHandler.ts (1)
1-1
: Explicit Module Resolution: Added File Extension in Import
Updating the import to use./BaseHandler.js
satisfies the ESM requirement for explicit file extensions and ensures that module resolution works correctly in the new environment.packages/server/src/handlers/DeleteHandler.ts (1)
1-1
: Explicit Module Resolution: Updated Import to Use '.js' Extension
Changing the import forBaseHandler
to./BaseHandler.js
ensures consistency across the codebase and aligns with the ESM module resolution standard adopted in this PR.packages/utils/src/test/Metadata.test.ts (1)
2-2
: ESM Import Compliance for Metadata Module.
The import statement on line 2 now explicitly includes the.js
extension. This update aligns with the project's transition to ESM and ensures consistent module resolution.packages/utils/src/test/stores.ts (1)
7-7
: Updated Import Source for 'Upload' and 'Uid'.
The change on line 7 switches the module source from@tus/server
to@tus/utils
to reflect the new package organization under ESM. Please verify that the implementation of these entities in@tus/utils
behaves as expected.packages/utils/src/test/Uid.test.ts (1)
3-3
: Updated Import Path for Uid Module.
The import statement on line 3 now explicitly points to../models/index.js
, ensuring ESM compatibility. Confirm that theUid
module is correctly exported from this file.packages/utils/src/models/DataStore.ts (1)
4-4
: Explicit File Extension for 'Upload' Import.
By updating the import on line 4 to use./Upload.js
, the change guarantees proper module resolution in a strict ESM environment. This adjustment is consistent with the overall migration strategy.packages/utils/src/models/Metadata.ts (1)
1-1
: Explicit File Extension in Type-only Import.
The modification on line 1 changes the import for theUpload
type to include the.js
extension, ensuring that type references remain accurate and the module is correctly resolved in an ESM context.packages/server/src/handlers/HeadHandler.ts (1)
1-1
: LGTM! Update to use explicit .js extension for ESM compatibility.The explicit .js extension is correctly added to the import statement, which is required for ECMAScript Modules (ESM).
packages/server/src/handlers/PatchHandler.ts (1)
4-4
: LGTM! Update to use explicit .js extension for ESM compatibility.The explicit .js extension is correctly added to the import statement, which is required for ESM compatibility.
packages/utils/src/test/StreamSplitter.test.ts (1)
6-6
: LGTM! Updated import path to use explicit .js extension for ESM compatibility.The import path has been correctly updated to use the explicit .js extension and points to the index.js file directly, which is necessary for ESM compatibility.
packages/utils/src/kvstores/Types.ts (1)
1-1
: LGTM! Updated import path to use explicit .js extension for ESM compatibility.The import path has been correctly updated to use the explicit .js extension and now points to the index.js file directly, which is required for ESM compatibility.
packages/server/src/test/PostHandler.test.ts (1)
9-10
: LGTM! Updated import paths for ESM compatibility and package structure.Two key changes have been made here:
- The import path for PostHandler now uses the explicit .js extension required for ESM
- MemoryLocker is now imported directly from the @tus/server package instead of using a relative import
Both changes align with the ESM migration goals of this PR.
packages/server/src/handlers/BaseHandler.ts (1)
3-3
: ESM Import Extension for ServerOptions
The updated import now explicitly includes the.js
extension, ensuring proper module resolution in environments that require fully specified paths.packages/server/src/test/HeaderValidator.test.ts (1)
3-3
: Explicit File Extension for HeaderValidator Import
Changing the import path to include the.js
extension aligns with ESM module requirements and improves clarity in module resolution.packages/utils/src/kvstores/FileKvStore.ts (1)
4-5
: Updated Import Paths for ESM Consistency
The modifications to importKvStore
from./Types.js
andUpload
from../models/index.js
ensure that the module references are explicit. This change complies with Node.js ESM resolution and promotes consistency across the codebase.packages/utils/src/kvstores/MemoryKvStore.ts (1)
1-2
: Explicit Import Extensions for MemoryKvStore
Updating the imports to include.js
in bothUpload
andKvStore
paths is a necessary step for ESM compliance. The changes enhance clarity and avoid ambiguity in module resolution.packages/server/src/test/BaseHandler.test.ts (2)
3-3
: Updated BaseHandler Import with Explicit Extension
The change to importBaseHandler
from'../handlers/BaseHandler.js'
ensures that the code adheres to ESM requirements by explicitly specifying the file extension.
5-5
: Refactored MemoryLocker Import Location
ImportingMemoryLocker
from@tus/server
reflects the updated module organization and ensures consistency across imports following the ESM conversion.packages/gcs-store/src/test/index.ts (2)
3-3
: Import path updated correctly to package reference.The change from a relative import to an absolute package import (
'@tus/gcs-store'
) is appropriate for the ESM transition and improves module resolution.
5-5
: Correctly updated import path with .js extension.Updating the import path to include the
.js
extension is necessary for ESM compatibility. The path now correctly points to the compiled file in the dist directory.packages/server/src/test/PatchHandler.test.ts (3)
5-6
: Stream imports properly updated.The updated imports for stream modules from Node.js core libraries are correctly structured for ESM. Adding the explicit import for
streamP
fromnode:stream/promises
improves code clarity.
10-10
: Import path correctly includes .js extension.The explicit
.js
extension is required for ESM and has been properly added to the import path.
12-12
: Updated to package import correctly.Changed from a relative import to an absolute package import (
'@tus/server'
), which is more appropriate for the ESM transition and improves module resolution.packages/s3-store/src/test/index.ts (1)
7-8
: Import paths updated correctly for ESM compatibility.The changes from relative imports to package imports and explicit path with
.js
extension align with ESM requirements and improve module resolution.packages/server/src/test/DeleteHandler.test.ts (1)
8-9
: Import paths correctly updated for ESM.Both imports have been properly updated to follow ESM conventions: adding the
.js
extension and using a package import instead of a relative path forMemoryLocker
.packages/azure-store/src/test/index.ts (1)
3-4
: Import changes look good for ESM compatibility.The changes to the import statements correctly:
- Use the package import for AzureStore, which is a best practice and will work with the "exports" field in package.json
- Include the explicit .js extension for the stores import, which is required in ESM
These changes align perfectly with the PR objectives of transitioning to ESM.
.changeset/tricky-paws-hear.md (1)
1-10
: Changeset looks appropriate for the scope of changes.The version bumps correctly reflect the nature of the changes:
- Major version bumps for packages being converted to ESM-only, which is a breaking change
- Minor version bump for @tus/utils, suggesting backward-compatible new features
The explanatory note about Node.js >= 20.19.0 supporting
require(esm)
is valuable information for users who might be concerned about compatibility.packages/utils/src/test/Upload.test.ts (1)
4-5
: Import path changes are correct for ESM compatibility.The changes correctly:
- Include the explicit '.js' extension, which is required in ESM
- Update the relative paths to properly reference the modules from the test location
These changes follow the ESM module resolution rules and maintain the same functionality.
packages/server/src/test/GetHandler.test.ts (2)
9-9
: Import path change is correct for ESM compatibility.The change correctly adds the explicit '.js' extension and updates the relative path, which is required for ESM module resolution.
12-12
: Good improvement in importing MemoryLocker from the package.Changing from a relative import to importing from '@tus/server' is a better practice:
- It treats MemoryLocker as part of the public API
- It ensures the component is properly exported through the package's "exports" field
- It creates a cleaner dependency structure
This change aligns well with modern module practices and the ESM transition.
packages/server/src/test/OptionsHandler.test.ts (2)
5-5
: Updated import path with explicit .js extensionThis change correctly adds the
.js
extension required by ESM modules. This aligns with the PR's objective to transition to ECMAScript modules.
13-13
: Switched to package import for MemoryLocker and ServerOptionsThe import has been updated from a relative path to an absolute import from the
@tus/server
package. This approach provides better module resolution and maintainability when working with ESM.packages/file-store/src/test/index.ts (2)
10-10
: Updated to package import for FileStore componentsChanged from relative import to direct package import. This is a good practice that allows for better encapsulation and cleaner imports.
13-13
: Added explicit file extension for shared test utilitiesThis import now correctly includes the
.js
extension and points to the compiled output in thedist
directory instead of the source. This is required for ESM compatibility.packages/utils/src/index.ts (1)
1-3
: Added explicit .js extensions to all exportsAll exports have been updated to include the
.js
extension, which is required for proper ESM compatibility. This is a critical change for the module system transition.packages/server/src/test/HeadHandler.test.ts (2)
6-6
: Updated import path with explicit .js extensionThe import for HeadHandler now correctly includes the
.js
extension required by ESM. This is consistent with the changes made throughout the codebase.
7-7
: Switched to package import for MemoryLockerChanged from a relative import to an absolute import from the
@tus/server
package. This approach is more maintainable when working with ESM as it leverages the package's exports.test/package.json (3)
5-5
: ESM Mode Declaration Added
The addition of"type": "module"
ensures that this package is treated as an ECMAScript module. This change is in line with the overall PR objective of transitioning packages to ESM.
8-8
: Updated Test Script for ESM Compilation
Thetest
script now runs the tests directly from the compileddist
files, removing TypeScript-specific runtime options. This simplifies the testing process under the ESM paradigm. Please verify that the build output consistently places tests in the expecteddist
directory.
31-31
: Dependency Adjustment Verification
The removal ofts-node
fromdevDependencies
is appropriate given the move to ESM. Additionally, ensure that the retained"throttle": "^1.0.3"
dependency is intentionally maintained and compatible across the project.packages/utils/src/kvstores/RedisKvStore.ts (1)
2-3
: Updated Import Paths to Include File Extensions
The import paths forKvStore
andUpload
now explicitly include.js
(and/index.js
), which is essential for proper module resolution in an ESM environment. This update is clear and consistent with the project-wide changes.packages/utils/src/kvstores/IoRedisKvStore.ts (1)
2-3
: Explicit File Extensions in Import Statements
The modifications to import paths—changing to include.js
in"./Types.js"
and"../models/index.js"
—align with the new ESM requirements. This ensures that the module resolution works as expected in Node.js environments using ESM.packages/utils/src/kvstores/index.ts (1)
1-5
: Consistent Export Statements with Explicit Extensions
The export statements have been updated to include explicit.js
extensions. This consistency is crucial for correct module resolution in an ESM context, making the package easier to consume by other modules.packages/server/src/index.ts (2)
1-3
: Revised ESM Export Declarations
Updating the export paths to explicitly include.js
forServer
,types
, andlockers
ensures compliance with ESM standards. This change improves clarity in module resolution and aligns with the broader project transition.
4-4
: External Module Export Reference Maintained
The re-export from@tus/utils
is correctly preserved. Just ensure that@tus/utils
is also fully updated to support ESM, as expected per the project’s overall objectives.packages/server/src/handlers/GetHandler.ts (2)
1-1
: ESM Import for BaseHandler Updated:
The updated import now explicitly includes the.js
extension. This change is required for proper ESM resolution and is consistent with the project’s move to an ESM-only architecture.
4-4
: ESM Import for RouteHandler Updated:
Changing the import to include the.js
extension ensures that the module resolution works correctly in Node environments that require explicit file extensions.packages/file-store/src/index.ts (2)
10-10
: Updated Import for Configstore Module:
The import now explicitly references./configstores/index.js
, which is essential for ESM compatibility and avoids any ambiguity in module resolution.
13-13
: Updated Export Path:
Exporting from./configstores/index.js
ensures that the package’s public API is correctly exposed under the ESM guidelines. This helps maintain consistency across the package.packages/file-store/tsconfig.json (2)
4-5
: Updated Project References and Inclusion:
Thereferences
array now points to../utils/tsconfig.json
and the addition of"include": ["src"]
streamlines the TypeScript project setup. This update is in line with the unified configuration approach across packages.
7-8
: Refined Compiler Options:
Setting"rootDir": "src"
and"outDir": "dist"
ensures that source files are correctly compiled into the designated output directory. This change improves the build process and maintains consistency with the ESM output requirements.packages/server/tsconfig.json (2)
4-7
: Updated TS References:
The references now include paths to../utils/tsconfig.json
and../file-store/tsconfig.json
, which aligns with the new configuration strategy and ensures that shared settings are centralized.
8-11
: Standardized Compiler Options:
Introducing"rootDir": "src"
and"outDir": "dist"
standardizes the source and distribution directories, promoting a cleaner and more predictable build process.packages/s3-store/tsconfig.json (2)
4-5
: Simplified TS Configuration:
The updated"references": [{ "path": "../utils/tsconfig.json" }]
along with"include": ["src"]
simplifies the project configuration. This is consistent with the changes in other packages and supports the overall ESM migration.
7-8
: Updated Compiler Options:
By setting"rootDir": "src"
and"outDir": "dist"
, the configuration now clearly defines where source files reside and where the build output should be placed. This aligns with the broader strategy applied across the codebase.packages/azure-store/tsconfig.json (2)
4-5
: Configuration correctly updated for ESM support.The reference to
../utils/tsconfig.json
and the addition ofinclude: ["src"]
align with the ESM configuration pattern applied across packages in this PR.
7-8
: Appropriate output configuration for TypeScript compilation.Setting
rootDir
to "src" andoutDir
to "dist" ensures TypeScript correctly processes the source files and outputs them to the appropriate directory structure, which is essential for the ESM module resolution to work properly.packages/server/src/test/Server.test.ts (2)
13-13
: Updated import statement for ESM compatibility.The import has been correctly changed from a relative path to using the package name, which aligns with best practices for module imports in ESM.
21-21
: Properly migrated from CommonJS to ESM path resolution.The code correctly updates from using
__dirname
(which is not available in ESM) toimport.meta.dirname
, which is the appropriate equivalent for resolving file paths in ECMAScript modules.packages/gcs-store/tsconfig.json (2)
4-5
: Configuration correctly updated for ESM support.The reference to
../utils/tsconfig.json
and the addition ofinclude: ["src"]
align with the ESM configuration pattern applied across packages in this PR.
7-8
: Appropriate output configuration for TypeScript compilation.Setting
rootDir
to "src" andoutDir
to "dist" ensures TypeScript correctly processes the source files and outputs them to the appropriate directory structure, which is essential for the ESM module resolution to work properly.packages/utils/src/models/index.ts (1)
1-8
: Correctly updated import paths with .js extensions for ESM.The addition of
.js
extensions to all import paths is required for ESM compatibility. In ECMAScript modules, file extensions must be explicitly specified in import paths, unlike CommonJS where they are optional.packages/server/src/handlers/PostHandler.ts (3)
4-4
: Explicit File Extensions for ESM CompatibilityThe updated import for
BaseHandler
now includes the.js
extension. This change ensures that module resolution works correctly in an ESM-only environment.
14-14
: Updated Import for ValidatorThe import for
validateHeader
now explicitly includes the.js
extension. This aligns with the project’s transition to ESM and promotes consistent module resolution.
16-16
: Type Import Adjustment for ESMUpdating the import for types (
ServerOptions, WithRequired
) to include the.js
extension is necessary in an ESM context and helps avoid potential runtime resolution issues.packages/server/src/server.ts (2)
8-18
: ESM Import Updates in ServerAll import statements for handlers, validators, types, and utility modules have been updated to include the
.js
extension. This change is critical for proper ESM module resolution and ensures consistency across the codebase.
181-182
: Explicit Typing forinvalid_headers
Declaring
invalid_headers
with an explicit typestring[]
improves type clarity and enforces the expected contents of the array.packages/file-store/package.json (3)
6-8
: ESM Package ConfigurationBy updating the
"main"
,"exports"
, and adding the"type": "module"
field, the package now correctly signals its ESM nature. This is essential for compatibility with Node.js versions that enforce explicit ESM usage.
12-16
: Refined Package File InclusionThe
"files"
array now explicitly includes the"dist"
and"src"
directories and excludes test files using"!test*"
. This adjustment ensures that only the necessary artifacts are published with the package.
19-21
: Enhanced Testing ScriptsIntroducing a
pretest
script to run the TypeScript compiler (tsc --build
) before tests and adjusting thetest
script to target./dist/test/*.js
ensures that tests are executed on compiled code, reducing mismatches between source and runtime behavior.packages/s3-store/package.json (3)
6-8
: ESM Configuration for S3 StoreThe updates to the
"main"
,"exports"
, and"type"
fields standardize the module format to ESM. This update is crucial for ensuring consumers can load the module correctly with modern Node.js.
13-16
: Optimized Files DistributionAdjusting the
"files"
array to include"src"
(in addition to"dist"
) and exclude test files using"!test*"
refines the package contents. This helps deliver a clean and lean module to end users.
19-21
: Test Script UpdateThe test command has been updated to run tests from the compiled JavaScript in
./dist/test/*.js
with an explicit timeout. This guarantees that tests are executed on the built files, ensuring compatibility with the ESM build.packages/server/package.json (3)
6-8
: ESM Module TransitionThe modifications to
"main"
,"exports"
, and the addition of"type": "module"
facilitate a smooth transition to ESM. These changes help maintain consistency with the broader project updates and ensure compatibility with the new Node.js requirements.
13-16
: Streamlined Package AssetsThe
"files"
array now exclusively includes the"dist"
and"src"
directories while excluding test files via"!test*"
. This targeted inclusion reduces package bloat by omitting unnecessary test assets.
19-21
: Pretest and Test Script EnhancementAdding a
pretest
step to compile TypeScript and updating the test script to execute tests from./dist/test/*.js
(with a specific timeout) ensures that only compiled, production-ready code is tested, thereby eliminating source-level discrepancies.packages/gcs-store/package.json (2)
6-8
: ESM Fields Update
The updated"main"
,"exports"
, and"type"
fields are correctly set to support ECMAScript modules. This aligns well with the new Node.js version requirements.
18-22
: Updated Scripts for ESM Build and Testing
Adding the"pretest": "tsc --build"
script ensures that the TypeScript build runs before tests, and modifying the test command to run from the./dist/test
directory is consistent with the ESM output. The inclusion of a timeout (--timeout 30000
) also seems appropriate.packages/utils/package.json (2)
6-8
: Consistent ESM Configuration
The changes to set"main": "./dist/index.js"
, add"exports": "./dist/index.js"
, and include"type": "module"
correctly signal that this package now uses ESM.
18-22
: Refined Test Script and Dependency Cleanup
Switching to a test script that runs tests from the compiled JavaScript files (./dist/test/*.js
) and introducing the"pretest": "tsc --build"
command is a good move for an ESM environment. The removal ofts-node
from the devDependencies further simplifies the test setup.packages/azure-store/package.json (2)
6-8
: Proper ESM Declaration
The updated"main"
value with a relative path, the newly added"exports"
field, and the"type": "module"
declaration all correctly configure the package for ECMAScript modules.
18-22
: Streamlined Build and Test Scripts
The addition of"pretest": "tsc --build"
guarantees that your TypeScript is compiled before testing, while the updated test command correctly references the output directory (./dist/test/*.js
). This change is consistent with the ESM transition and should help prevent runtime issues.
Now that we make the required Node.js version
>=20.19.0
(#723), which is the specific release that stabilizedrequire(esm)
, we might as well output ESM as it makes no difference anymore. We keep the same level of compatibility.Notable changes:
"type": "module"
and"exports"
in allpackage.json
's."exports"
or fromdist/
(instead of/src
) if not exported."module": "NodeNext"
intsconfig.base.json
(done in Bump required Node.js version from 16 to 20 #723, which this branch is based off)..js
extensions which is the majority of this diff.