Prepare for code generation by moving generated code to separate files

[sam-1pass]

Move all constant code to client_util.ts and leave only generated code in client.ts in preparation for automating code generation.

[Marton6]

This looks good so far! Can you resolve the merge conflicts on it and give the MR a more descriptive title and description, @sam-1pass?

The description could mention why we're doing this: in preparation for automating code generation.

[Marton6]

@sam-1pass I improved the title a bit more to also express the intent behind the change. This makes it easier to understand why we made this change when we read the PR title

[Marton6]

In package.json we define the package's exports like so:

"exports": {
    ".": {
      "types": "./dist/client.d.ts",
      "default": "./dist/client.js"
    }
  },

This tells npm to look into client.js (which is compiled from client.ts) and make all exported types and functions accessible from outside the package.

By moving things out of this file, we're making them inaccessible to the SDK users. You can see that running the examples no longer works:

npm run commonjs-example

fails.

I think we should change where we export types/functions from so that all the types that used to be accessible to the SDK users will still be accessible after this MR is merged.

@AndyTitu, you know way more about packaging node projects. Is my assessment correct? How do you think we can best achieve this?

Also, could we write a unit test that would catch errors like this? (e.g. could we run the examples in the pipeline?)

[AndyTitu]

Yes, you're right, this refactor as it is right now would break the JS SDK. The exports.default acts as the entry point of the npm module. All that's exported in the exports.default file will be the default exports of the entire module, whereas exports.types marks the exported TypeScript types.

There are a few ways to fix this:

1. Move the sdk.createClient function back into the client.ts file, since that's the only additional thing we would need to export to developers, besides the Client struct. (exporting the client struct will give users access to all the contained apis: secrets, items etc)

2. Make client-util.ts the package entrypoint. In this case, I would like another name for this file, as it's not just an util holder but rather the entry point to the whole module. I'm thinking sdk.ts?

[hculea]

Thanks for these options laying out! I was also thinking about solution 2, to ensure separation between generated code and the rest.

I am fine with swapping the name to sdk.ts 👍 - @sam-1pass can you have a look at that?

[sam-1pass]

Looking into option 2 now 👍

[hculea]

@Marton6 do Sam's latest changes address this concern?

[Marton6]

Well does the SDK export the types and functions the user needs?

[AndyTitu]

Tested the new import experience for the latest code version:

imo, this is everything the user needs access to for now: the Client, the createClient function and the util constants. These same components are exported for both typescript and javascript projects.

[Marton6]

This and the resolve function on the client.

I agree. If there was more stuff exported before and this is a breaking change, we should at least post a message about it in the developer workspace slack channel.

[AndyTitu]

Yes, that as well. But that's accessible via the client.secrets object as opposed to being a top level import

[Marton6]

Looks good to me but I haven't functionally reviewed it. I think @AndyTitu has tested it manually
.

[hculea]

I've confirmed that Andi functionally tested this. Should be good to go!