Skip to content
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

Update packaging to use subpath exports and moduleResolution node16 #784

Open
cprice404 opened this issue Aug 30, 2023 · 3 comments
Open

Comments

@cprice404
Copy link
Contributor

Today, we release our packages with all of the code nested in a dist dir. This is fine except that it means that in order to avoid forcing our users to have really weird/ugly imports that dig down into dist, we need to export all the important names from the main index.

node/ts/webpack all seem to support this newer concept called "subpath exports":

https://nodejs.org/api/packages.html#packages_subpath_exports

which would allow us to add exports like "./vector" -> "./dist/src/messages/responses/vector". Then our users could do imports like import {CreateVectorIndex} from @gomomento/sdk/vector, with none of the weird dist` stuff.

However, this requires consumers to use moduleResolution of node16 or bundler. These seem to be the preferred / best practice choices for "modern" applications:

https://www.typescriptlang.org/tsconfig#moduleResolution

but they are not the defaults, and thus I am concerned that it is too risky to introduce a change like this in our 1.x series.

We should definitely try to do this whenever we do a 2.0.

@cprice404
Copy link
Contributor Author

cc: just FYI: @malandis @bruuuuuuuce @pgautier404 @allenheltondev

@allenheltondev
Copy link

The way I read your message is that this is definitely a breaking change for people not using bundler or moduleResolution of node16.

Makes me lean toward a minor release (v1.1)

@cprice404
Copy link
Contributor Author

The way I read your message is that this is definitely a breaking change for people not using bundler or moduleResolution of node16.

I think it would be a breaking change, so that's why I'm not doing it now.

Makes me lean toward a minor release (v1.1)

Not sure I follow? It seems like it would need to wait until 2.x to me since it would be a breaking change?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants