🐛 fix: resolve dayjs plugin ESM imports in data-provider (0.8.507)#13851
Merged
Conversation
`parsers.ts` imported `dayjs/plugin/utc` and `dayjs/plugin/timezone`
without a file extension. The tsdown build externalizes all bare imports,
so it emitted those specifiers verbatim into `dist/index.mjs`. dayjs@1.11
ships no `exports` map, so under strict Node ESM the extensionless
subpaths fail with ERR_MODULE_NOT_FOUND ("Did you mean to import
'dayjs/plugin/utc.js'?"), breaking every strict-ESM consumer that
transitively imports data-provider (and data-schemas, which re-exports
it) — e.g. vitest suites in downstream apps.
Add the `.js` extension so the externalized imports resolve. With
moduleResolution: bundler the types still resolve from the plugin
`.d.ts`. Bump to 0.8.507 to supersede the broken 0.8.506 publish.
Verified: build clean, `dist/index.mjs` imports under strict Node ESM
(node --input-type=module), parsers specs 50/50.
Owner
Author
|
@codex review |
|
Codex Review: Didn't find any major issues. Hooray! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
fuuuzzy
pushed a commit
to fuuuzzy/LibreChat
that referenced
this pull request
Jul 7, 2026
…#13851) `parsers.ts` imported `dayjs/plugin/utc` and `dayjs/plugin/timezone` without a file extension. The tsdown build externalizes all bare imports, so it emitted those specifiers verbatim into `dist/index.mjs`. dayjs@1.11 ships no `exports` map, so under strict Node ESM the extensionless subpaths fail with ERR_MODULE_NOT_FOUND ("Did you mean to import 'dayjs/plugin/utc.js'?"), breaking every strict-ESM consumer that transitively imports data-provider (and data-schemas, which re-exports it) — e.g. vitest suites in downstream apps. Add the `.js` extension so the externalized imports resolve. With moduleResolution: bundler the types still resolve from the plugin `.d.ts`. Bump to 0.8.507 to supersede the broken 0.8.506 publish. Verified: build clean, `dist/index.mjs` imports under strict Node ESM (node --input-type=module), parsers specs 50/50.
ThomasVuNguyen
pushed a commit
to ThomasVuNguyen/LibreChat
that referenced
this pull request
Jul 15, 2026
…#13851) `parsers.ts` imported `dayjs/plugin/utc` and `dayjs/plugin/timezone` without a file extension. The tsdown build externalizes all bare imports, so it emitted those specifiers verbatim into `dist/index.mjs`. dayjs@1.11 ships no `exports` map, so under strict Node ESM the extensionless subpaths fail with ERR_MODULE_NOT_FOUND ("Did you mean to import 'dayjs/plugin/utc.js'?"), breaking every strict-ESM consumer that transitively imports data-provider (and data-schemas, which re-exports it) — e.g. vitest suites in downstream apps. Add the `.js` extension so the externalized imports resolve. With moduleResolution: bundler the types still resolve from the plugin `.d.ts`. Bump to 0.8.507 to supersede the broken 0.8.506 publish. Verified: build clean, `dist/index.mjs` imports under strict Node ESM (node --input-type=module), parsers specs 50/50.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
librechat-data-provider@0.8.506is a broken ESM publish.parsers.tsimports the dayjs timezone plugins without a file extension:The tsdown build externalizes every bare import, so it emits those specifiers verbatim into
dist/index.mjs.dayjs@1.11ships noexportsmap, so under strict Node ESM the extensionless subpaths fail:This breaks any strict-ESM consumer that transitively imports
data-provider— and@librechat/data-schemas, which re-exports it. It surfaced as 9 failing vitest suites in the admin-panel, which had to pindata-providerto exactly0.8.505to work around it.Fix
Add the
.jsextension so the externalized imports resolve under strict Node ESM. WithmoduleResolution: bundlerthe types still resolve from the plugin.d.ts, and the CJS build (require('dayjs/plugin/utc.js')) is unaffected. Version bumped to 0.8.507 to supersede the broken0.8.506.0.8.505was fine only because it predates the timezone feature that introduced these plugin imports.Verification
npm run build:data-provider— cleannode --input-type=module -e "import('./dist/index.mjs')"— resolves, 428 exports (wasERR_MODULE_NOT_FOUND)parsersspecs — 50/50 pass