Plan for 1.0
octref opened this issue · comments
Well, I haven't been spending much time on OSS for a while, and now I plan to get back to it. So here's a plan for 1.0. I'm guessing it'll take 2 months. This is a brain dump list and will change as things goes.
- Website: redo it. We have too many content there and it's hard to add new ones.
- Docs: redo it. Give it a better organization and make it easy to add new things.
- API: review the use cases and simplify the surface.
- New features
- Examples: make one for each major framework and keep it in the core repo.
- Samples: make sure each language has one.
- Theme/Grammar autofetching: auto-generate a changelog. Auto-open issue for added/deleted theme/grammar
- Infrastructure:
Todo – Meta
- Label all issues. Close ones without repro.
- Merge bug-fix PRs.
- Fix valid bugs.
- Release one last 0.x version. Feature freeze.
- Do the overhauling in
devbranch - Merge
devback to main for releasing 1.0
Todo – Open to contributions
- Examples: Create a vanilla/nextjs/vite official example
- Next 13: https://github.com/shikijs/next-shiki
- Vite
- Vanilla
You got this!
Excited!
I haven't been able to get Shiki working in Next.js when deployed to Vercel and I think a fix would fall under
API: review the use cases and simplify the surface.
You can see my struggles with trying to get it deployed to Vercel over in this repo: https://github.com/tom-sherman/shiki-server-components-demo It works great locally by the way, it's just deploying to vercel isn't compatible with the way shiki wants to read grammars and themes from the file system local to it's node_modules directory.
Wouldn't it be reasonable to adjust the README?
0.13.0 will be the last minor version
Wanted to give an update on my struggles, I was able to get it deployed to Vercel but I had to drop the shiki dependency :-/
In the end I used https://github.com/code-hike/lighter which feels like what Shiki 1.0 (or maybe 2.0?) could aim to be with regards to the API and the way things work.
True, it is not working with dynamic server component in Next.js when deployed to Vercel
We should replace this entire repo with @antfu's shikiji for 1.0, https://github.com/antfu/shikiji
And get plugin support in, then we can bring shiki-twoslash to be a shikiji plugin
The repo contains all the history, therefore it shouldn't be replaced.
The other repo is only 3 weeks old, but I guess @antfu could create a PR to re-do his rewrite on a branch (hopefully only the initial setup, then manually merge-pick the revisions from his repo into this branch), if it is sure that his changes are accepted he may do that?
We need consensus from pine
So I made a few API design changes in shikiji that I personally feel would be better in various ways. I am slowly discussing with @octref (he has other priorities) to reach a consensus on which changes/features to include in shiki 1.0, and then I will prepare the PR to port those changes back to shiki and eventually deprecate shikiji.
If you want to move faster, I'd be happy to hear your feedback on https://github.com/antfu/shikiji so we could roll out features to experiments, and eventually port back to shiki if they worked out.
A side note that I also made a shikiji-compat package trying to align with the current shiki behavior for easier migration, so you could use shikiji today. I already using it in sli.dev and it seems to working fine.
@orta I'd be happy to explore the plugin API design in shikiji that fits twoslash! Let me know if you have any initial ideas.
Realistically I can't think about anything hard for a month or two, so consider it on my backlog 👍🏻
I think your technique for integration twoslash into shikiji natively looks great, I don't think we need to go back to that - but I am re-raising that I think shikiji should replace shiki!
Any update on this
Talked to @octref and we made the consensus to merge shikiji back to shiki, I'll take the lead and start the work soon 🎉