It's time to say bye to pika (?)

[oscard0m]

Pika is the tool used in the build step for the Octokit JS ecosystem. The project was archived in April 2022, so it's basically unmaintained for almost a year.

On one hand, there is a security risk the moment the project and its internal dependencies are not being updated. On the other hand, this is an opportunity to check the state of the art of existing build/bundle tools out there to integrate into our pipeline, which is maintained and faster.

We have already hit a rock with semantic-release + npm@v9 + pika, so I would like to talk about this.

I would love to do some proof of concept with existing tools in JS/TS ecosystem, but before doing that, I would like to hear your thoughts on this (@octokit/extensibility-sdks @octokit/js-community).

Thanks

[wolfy1339]

Do we really want to undertake a big task like this when we are going to switch to ESM and new tools anyways?

If there's something that can fit our needs without too much work, it would be much better than the current situation.

[oscard0m]

Do we really want to undertake a big task like this when we are going to switch to ESM and new tools anyways?

Good point. I guess it depends on how far we are from that switch.

If there's something that can fit our needs without too much work, it would be much better than the current situation.

That would be ideal.

[gr2m]

I second what @wolfy1339 said, part of the motivation for https://github.com/octokit/octokit-next.js was to remove the need for Pika or anything similar altogether. Unfortunately I'm not aware of any similar tool that we could use as a drop in replacement. Octokit Next should have been completed a long time ago, unfortunately my work contract was not extended and the work has since not been prioritized.

[oscard0m]

Makes sense. Because we already merged this hot-fix, I'm creating an octoherd script to apply to all the repos.

[wolfy1339]

esbuild can work for our needs

• Supports TypeScript input
• Can output bundles for web, or node
• Bundling is optional

Though, it is not a pipeline like pika where we can just add plugins to get the different packages

[wolfy1339]

We would need to use the TypeScript compiler itself to generate the types, as esbuild strips them out
https://jamesthom.as/2021/05/setting-up-esbuild-for-typescript-libraries/

[wolfy1339]

I have played around with it, and it seems very promising.
There's only one thing we will need to look out for: type imports are not automatically removed from the output.
The solution to that is to mark those imports with the type assertion

import type { foo } from "bar";

We will need to copy over the license, readme and package.json files manually

[wolfy1339]

I created a Proof of concept over at @octokit/webhooks: octokit/webhooks.js@main...esbuild