fix(core): add more exports on llm/index

[yisding]

@marcusschiesser @himself65 why did we move away from just export * from every file in the directory? Is there a benefit to doing so? Clear downside is that we'll often forget to re-export things.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 209d4cd

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
llama-index-ts-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 29, 2024 1:19am

[himself65]

Add a mock ALL_AVAILABLE_ANTHROPIC_LEGACY_MODELS ALL_AVAILABLE_ANTHROPIC_MODELS

here https://github.com/run-llama/LlamaIndexTS/blob/main/packages/core/e2e/fixtures/llm/anthropic.ts

[himself65]

Clear downside is that we'll often forget to re-export things.

It's better to use import { CONSTANT } from 'llamaindex/llm/anthropic'

I'm releasing 0.3.0 and will support Cloudflare and others; not everything can be exported to the root index. #775

[yisding]

Thanks, so I'll make that change. The issue of not exporting things to the root (or at least to the root of the folders) is that it's very tough for users to figure out what is being exported from where without reading the code. Even if we autogen the API docs (currently broken) we also change the names of the files pretty regularly and move things around, so those imports will not be stable.

I think unless it's absolutely unfeasible, we should do our best to try to have everything importable from "llamaindex" 99% of our users are going to import things that way. (because even if we put it in the docs people won't read them) And for the more advanced users we can guide them to import from "llamaindex/[folder]" I don't think it's a good idea to tell people to import from a specific file.

[himself65]

I think unless it's absolutely unfeasible, we should do our best to try to have everything importable from "llamaindex" 99% of our users are going to import things that way. (because even if we put it in the docs people won't read them) And for the more advanced users we can guide them to import from "llamaindex/[folder]" I don't think it's a good idea to tell people to import from a specific file.

Yes, export everything as much as possible, but in my view. it's kind of the fault of our library. We should explicit provider sub-modules like
llamaindex/node, llamaindex/llms, llamaindex/embeddings, llamaindex/vectorStore, llamaindex/readers similar to llama-index python. (even if you check langchain.js, all their docs don't have root import code)
The benefit is the user can easily understood what this class is used for an approximate meaning and usage.

The pitfall for JS here is not all code can be run in all JS runtime(like Edge, Cloudflare...), which would cause extra costs for library maintainers to support multiple platforms.

I think putting everything into the top index file could cause other hidden dangers
if developer delivers to other platform, like import vector store in edge run,time which is not possible due to Node.js-related APIs

[himself65]

small nit: we could create src/llm.ts so that user don't need import by llamaindex/llm/index but llamaindex/llm