chore(*): build system improvements

[hntrl]

• use tsdown cli/configuration scheme instead of internal options
• make tsdown plugins individually addressable
• adds a barrel-dts plugin to fix some compatibility issues with commonjs dependants
• changes build scripts in each package

Fixes #9252
Fixes #9268

[changeset-bot]

🦋 Changeset detected

Latest commit: e748cf0

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 40 packages

Name	Type
@langchain/azure-dynamic-sessions	Patch
@langchain/google-cloud-sql-pg	Patch
@langchain/google-vertexai-web	Patch
@langchain/google-vertexai	Patch
@langchain/azure-cosmosdb	Patch
@langchain/google-webauth	Patch
@langchain/baidu-qianfan	Patch
@langchain/google-common	Patch
@langchain/mixedbread-ai	Patch
@langchain/google-gauth	Patch
@langchain/google-genai	Patch
@langchain/cloudflare	Patch
@langchain/anthropic	Patch
@langchain/mistralai	Patch
@langchain/cerebras	Patch
@langchain/deepseek	Patch
@langchain/pinecone	Patch
@langchain/weaviate	Patch
@langchain/mongodb	Patch
@langchain/cohere	Patch
@langchain/ollama	Patch
@langchain/openai	Patch
@langchain/qdrant	Patch
@langchain/tavily	Patch
@langchain/yandex	Patch
@langchain/nomic	Patch
@langchain/redis	Patch
@langchain/standard-tests	Patch
@langchain/groq	Patch
@langchain/textsplitters	Patch
@langchain/aws	Patch
@langchain/exa	Patch
@langchain/xai	Patch
@langchain/mcp-adapters	Patch
@langchain/community	Patch
@langchain/classic	Patch
@langchain/core	Patch
@langchain/eslint	Patch
@langchain/build	Patch
langchain	Patch

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

[christian-bromann]

As we are revisiting this: the idea of defining entry points via src property in exports of package.json I think made sense when we defined all build configs within @langchain/build. Now that we go back to workspace config files we could also define entry points there, e.g. as getBuildConfig parameter?

I don't see anything wrong with the current approach, except it is not standard conferment and vitest gets confused by this. What are your thoughts here?

[hntrl]

As we are revisiting this: the idea of defining entry points via src property in exports of package.json I think made sense when we defined all build configs within

Could you elaborate more on this? Do you mean we should be changing how the entry config option is populated? I saw that tsdown has an exports key that may be of interest:
https://tsdown.dev/reference/api/Interface.UserConfig#exports

[christian-bromann]

Currently package entries are defines within exports of package.json via input key, e.g.:

"./callbacks/base": {
  "input": "./src/callbacks/base.ts",
  "require": {
    "types": "./dist/callbacks/base.d.cts",
    "default": "./dist/callbacks/base.cjs"
  },
  "import": {
    "types": "./dist/callbacks/base.d.ts",
    "default": "./dist/callbacks/base.js"
  }
},

This is not standard conferment and other tools may get thrown off by this. Using this exports function would be great, can we give this a shot?