Tooling suggestions

[martines3000]

Hi, I hope this is the correct place to open the discussion.

I am using this library and most of the @iden3 TypeScript libraries in our project, and I greatly appreciate the work you are doing.
When I was looking at the repository and code of the js-sdk and the @iden3 libraries, I noticed a couple of possible improvements mostly related to the build and tooling side of things. Furthermore, I wanted to avoid creating unnecessary issues, as these are only suggestions, so I opened this discussion first. If you agree with any of them, I am more than happy to help to prepare the initial PRs.

1. Use Node LTS Version, currently v20 for workflows, especially the publishing workflows. For testing and linting, the LTS Version can be combined with the next upcoming LTS version, in this case v22 (which is not yet released). A good way to manage the Node version in the repository is using the .nvmrc file. Workflows can read from it and if you use a node version manager, you can easily switch to the correct version when working on a specific repository.
2. Update TypeScript to version 5. This is probably a breaking change.
3. Switch package to "type": "module" (combined with point 4 and 5).
4. Remove outDir in tsconfig.json and use "moduleResolution": "Bundler" instead of "moduleResolution": "Node"
5. I would recommend using Tsup as a bundler for both CJS and ESM, as it makes things much simpler and also allows for great code splitting, tree-shaking, outputting both d.ts and d.cts declaration files and is fast. Bundling different declaration files ensures better compatibility for CJS and ESM. Tsup also allows for outputting the iife format, but I don't think you can replace Rollup with it, as Rollup prepares the UMD bundle, which is not supported by Tsup.
6. Replace testing libraries Mocha, Chai, and Jest with Vitest. It is faster, has a Jest expect compatible API, Chai is built in, etc… Replacing the existing testing library is probably not as big of a task as it sounds like because Vitest is almost plug-and-play with Jest.
7. Maybe use Dependabot for more than just the @iden3 libraries. I am not sure about this one, but I see that the did-jwt library is already 2 major versions behind the latest release. Perhaps this will help avoid future issues and make the transitions between updates smoother.
8. More a question than a suggestion, is the peerDependencies in package.json really needed, or would it be enough to just move those packages under the dependencies field?

These are just suggestions, so feel free to ignore them if you are happy with your current tooling.

[Kolezhniuk]

Hi @martines3000! Thanks for opening discussion. Let me share my thoughts

1. Sounds good, feel free to contribute, I don't see any issues with that
2. Reasonable point, It could be a big task so it needs further discussion with the team, estimate efforts, to plan this work etc
3. Make sense
4. Also +
5. Not sure about this bundler, seems it's just TS adopted wrapper over esbuild (in that case better to use esbuild because it's more flexible and it supports iife format) but frankly speaking - It's not important what bundler using - main goal to support libraries for all possible platform and build. But if you could manage build process in easier way - feel free to contribute
6. I don't mind to make all packages to use one test runner, if you have passion - go ahead :)
7. We can try
8. The main goal to avoid package duplication, and achieve version compatibility. With peer deps we can more or less guarantee that functionality of the library tested and working
   Thanks
   cc @vmidyllic

[vmidyllic]

@martines3000 @Kolezhniuk

no problem with such suggestions, we can do it iteratively, most of them make sense. Feel free to contribute

[martines3000]

Thanks for the prompt reply. Iteratively with small PRs makes the most sense.
I will go step by step and contribute some small PRs the next time I get some extra time.