feat: tsup, pnpm and new build system

[productdevbook]

close https://github.com/supertokens/supertokens-node/issues/413 close https://github.com/supertokens/supertokens-node/issues/459

• dynamic build -> export dist
• pnpm support
• esm, cjs support

[rishabhpoddar]

hey @productdevbook could you also tell if this a breaking change for the user? For example, will the import statements for the user change in any way for any recipe / function etc?

[productdevbook]

It should not affect it in any way, because I took the same paths. I can even create a playground for testing purposes.

[productdevbook]

[rishabhpoddar]

Okay. Im going to try and remove all the newly added @ts-ignore annotations before merging this PR.

Also, i see the you have removed the build folder and instead using dist, but dist itself is not part of the git repo (which is fine). This would affect the npm publish process right? Also, if someone is using the github repo directly in the npm command (like npm i git+https://github.com:supertokens/supertokens-node#14.0), how would they go about generating the required dist folder (for the package to work)

[productdevbook]

Okay. Im going to try and remove all the newly added @ts-ignore annotations before merging this PR.

Also, i see the you have removed the build folder and instead using dist, but dist itself is not part of the git repo (which is fine). This would affect the npm publish process right? Also, if someone is using the github repo directly in the npm command (like npm i git+https://github.com:supertokens/supertokens-node#14.0), how would they go about generating the required dist folder (for the package to work)

yes, used dist. example npm publish first build working and after send. package.json in

  "files": [
        "dist",
        "LICENSE",
        "README.md"
    ],

only send data.

[productdevbook]

npm i git+https://github.com:supertokens/supertokens-node#14.0

I do not know about this. normally it should not be kept on dist vs github in any way.

[rishabhpoddar]

I do not know about this. normally it should not be kept on dist vs github in any way.

Right, we do have requirements that we need the sdk to work even with directly using the git repo. Therefore, we would need the dist folder to be a part of the github repo as well (which is why earlier we had the build folder as well).

If you can think of a better solution to this, it would be great.

[productdevbook]

I can't find a solution to this, people who will use it will pr and create and export their github dist using their own url. This should not be in the main library. The solution is actually that simple. We already do the same thing in many libraries.

1. fork and build and push. and me github url copy and paste.

[rishabhpoddar]

I'm afraid that won't work for us. Maybe we can add a post npm install hook to do the TS compilation for such users. But we do require some solution that universally works even when pulling the GH repo directly. This is a hard requirement for us i'm afraid.

[productdevbook]

Since it will be an npm package and it is a suitable external build, people will use it according to the package versions anyway. In addition, users who want to use github url, which is a very special situation, should do as I said. It's a must. There is a postinstall structure in npm, but it is very inefficient in this structure.