Contributing to Vite+ Inside Stories — Vue Fes Japan 2026 Speaker Notes
This is the script of my talk "Contributing to Vite+ Inside Stories" at Vue Fes Japan 2026. I gave the talk in Japanese. This is an English translation, with links to the Issues and PRs that I talk about.
{% embed docswell.com %}
{% embed vuefes.jp %}
Introduction
Hello, everyone!
My slides are in English, but I will speak in Japanese today, because I am still learning English.
I hope you enjoy my talk!
Today, I want to look back on the contributions that I made to Vite+.
I will show the Issues and PRs that I worked on, and tell you what I was thinking at that time.
This is not a difficult technical talk. It is a look back at what I did, so please relax and listen.
At first, I worked on Vite+ as an individual contributor. After I joined the Core Team, my work changed. I started to investigate Issues and review PRs.
Today, I will also talk about how my way of thinking about open source software (OSS) changed during that time.
Let me introduce myself. My name is Naoki Haba.
In my free time, I work on Vite+ every day as a Core Team member.
What is Vite+?
Before the main topic, let me introduce Vite+.
Vite+ is a unified toolchain. It puts many tools for web development into one package.
In daily development, you start a development server, run tests, and lint and format your code.
To do this, you usually install many tools, and each tool has its own configuration and commands.
Vite+ puts these tools together, so you can use all of them from one CLI, vp.
You probably know many of the tools inside it.
It uses Vite for the development server and application builds, Vitest for tests, Oxlint for linting, and Oxfmt for formatting.
You run them with commands such as vp dev, vp test, and vp lint.
vp pack builds libraries, and it uses tsdown. I will talk about tsdown again later, in the migration part.
Now, let me tell you about my first contribution.
My journey as a contributor
My first contribution: vp create
The first problem that I worked on was in vp create.
vp create makes a new project from a template.
When I used it, I typed the name of a template that did not exist. The command showed the pnpm 404 error as it was.
With that error, it was hard to see what I did wrong.
I looked on GitHub, and someone had already reported the same problem as an Issue.
{% embed vite-plus#828 %}
So I read the code and followed the steps that it ran.
I found that the command ran the package manager without first checking if the package existed on npm.
Because of this, when it did not find the template, it showed the pnpm error.
This is the PR that fixed it.
{% embed vite-plus#1055 %}
Before it runs the package manager, the command now asks the npm registry if the package exists.
If the registry returns 404, the command shows that it did not find the template, and then it stops.
The message also tells you that vp create --list shows the available templates.
This was my first PR to Vite+.
It was a small change. But I read the real code and fixed a problem that I had when I used the tool.
After that, I started to look at other Issues, a little at a time.
Migrating Node.js version settings
At about the same time, I wanted to use Vite+ at work.
But existing projects already have a Node.js version setting and configuration for many tools.
I wanted to know how to move those settings to Vite+.
So I looked at vp migrate.
This command migrates an existing project to Vite+.
Rewriting configuration files sounds easy. But if the migration changes the Node.js version that the project uses, that is a problem.
So I had to think about two things: how to read the old settings, and how to make the project work the same way after the migration.
My first task here was to migrate the Node.js version setting.
{% embed vite-plus#1158 %}
Two files can set the Node.js version for a project: .nvmrc and .node-version.
Vite+ uses .node-version, but projects that use nvm often have a .nvmrc file.
So I changed vp migrate. When it finds .nvmrc, it migrates the file to .node-version.
{% embed vite-plus#1159 %}
For example, if the file contains a version number such as 20.11.0, the command copies that value.
If the value starts with v, the command removes the v.
Up to here, the command only cleans up the value and copies it. But .nvmrc can contain values that are not version numbers.
I was not sure how to handle those values.
For example, .nvmrc can contain node instead of a version number.
node means "use the latest release of Node.js".
lts/* means "use the latest LTS release".
These two look similar, but they do not always give the same version.
So, at first, when the file contained node, the command showed a warning and stopped the migration.
If the command changed node to LTS without asking, the project could get an older Node.js version. I did not think that was correct.
But when I opened the PR, a reviewer suggested that converting it to LTS might be fine.
At about that time, I had also read an announcement. From Node.js 27, every major version moves to LTS after its release.
{% embed nodejs.org %}
Because of this, I changed the command to convert node to lts/* and continue the migration.
But the new value does not mean the same thing as the old one, so the command writes a log message about the conversion.
At first, I thought this task was only about copying the contents of a configuration file.
But when I did it, I found cases where the command could not copy the old setting as it was.
I gave priority to keeping the meaning of the old setting. The reviewer gave priority to letting the migration continue.
Neither view was wrong. We had to decide which behavior was best for Vite+.
Talking about the direction with other members, before and after writing code, is one thing that makes OSS contribution interesting for me.
Up to here, I worked with Node.js, which I knew well. Next, I worked in a different area.
Adding Nushell support
That was support for Nushell.
Nushell is a shell, like Bash or Zsh. You run commands in a terminal with it.
Vite+ has a feature, vp env, that switches the Node.js version. The Issue asked to make this feature work in Nushell.
{% embed vite-plus#1144 %}
This part of Vite+ uses Rust. I had never used Rust in a real product before.
So I started by reading the existing code for Bash and Fish, to learn what it did.
I looked up the types and syntax that I did not know, and checked step by step how to do the same thing in Nushell.
But reading the Rust code was not enough. I also had to learn about the Nushell script that the code generates.
For example, look at this code:
# Does not work
source "$HOME/.vite-plus/env.nu"
# Works
source ~/.vite-plus/env.nu
In the first example, the path that goes to source starts with $HOME.
In Bash and similar shells, you often write the home directory like this.
But in Nushell, $HOME inside double quotes does not expand. Also, Nushell writes environment variables as $env.HOME.
So I thought that I only had to change that. But it still did not work.
The reason is that Nushell's source decides which file to load when it parses the script, before any command runs.
{% embed nushell.sh %}
So you cannot use a runtime environment variable in that path.
I read the Nushell documentation again, and changed the path to start with a tilde, as in the second example.
With a tilde, Nushell can find the home directory when it parses the script.
{% embed vite-plus#1312 %}
The Rust code only makes a string. But I had to think about how Nushell reads that string.
So I ran the script in Nushell to check each change.
Before this, I had never written Rust code for a real product.
I work as a frontend engineer, so I do not use Rust at work.
I had solved some LeetCode problems in Rust, and that was all.
When you study alone, you usually stay with what you already know. In OSS, you cannot do that.
If you want to fix a problem, you must learn the language or the specification, even if you do not know it.
In this case, I had to learn about Nushell as well as Rust.
I did not understand everything at the start. I looked things up, tried them, got help in reviews, and learned a little at a time.
It was good study for me, and it also helped a tool that I use. I think that is a very good deal.
Joining the Core Team
I continued like this. I investigated Issues that interested me, and I opened PRs.
About one month after my first PR, the Vite+ Core Team invited me to join.
I was very surprised.
It was my first time on the core team of an OSS project. The members were engineers that I had looked up to for a long time.
I never thought that I would work on the same team as them.
After I joined the team, I started to look at Issues and PRs from other people, in addition to my own PRs.
For example, when someone reports an Issue, I first try to reproduce it on my machine.
If I can reproduce it, I look for the cause. If the report does not have enough information, I ask the reporter.
I also review more PRs from other people.
But the code alone does not always tell you why a change is necessary.
So I read the related Issues and past discussions. When necessary, I also read the code of projects other than Vite+.
Now I will show some of the work that I did as part of this.
Migrating from tsdown to Vite+
The first one is a problem in the migration from tsdown to Vite+.
tsdown is a tool that builds TypeScript libraries.
Vite+ could already migrate projects from tsdown. But after the migration, some projects got TypeScript errors.
{% embed vite-plus#1500 %}
I investigated and found that references to the tsdown/client type definitions stayed in the project after the migration.
So I added a matching export, vite-plus/pack/client, to Vite+, and made vp migrate rewrite the references.
{% embed vite-plus#1501 %}
But import statements were not the only place with these references. They were also in type declarations, in tsconfig.json, and in other places.
{% embed vite-plus#1502 %}
So I had to add a migration step for each of these formats.
#1541 rewrites import and declare module statements.
{% embed vite-plus#1541 %}
#1542 rewrites compilerOptions.types in tsconfig.json.
{% embed vite-plus#1542 %}
Replacing a dependency sounds easy. But I had to make sure that TypeScript still worked after the migration.
Supporting GitLab CI with setup-vp
Next, let me talk about CI.
If you use Vite+ at work, you want to use it in CI too, and not only on your machine.
For this, I worked on setup-vp.
setup-vp installs Vite+ in a CI environment, and sets up dependencies and caches.
At that time, it supported GitHub Actions, but not GitLab CI.
So, to use Vite+ on GitLab, you had to write the install steps yourself.
{% embed setup-vp#88 %}
I added a template, so that you do not have to write those steps yourself on GitLab CI.
{% embed setup-vp#97 %}
Now I am a collaborator on setup-vp, and I help to maintain it.
For this work, I did not start by writing code. First, I wrote the design in an RFC.
An RFC is a document that proposes a feature or a design, so that the team can discuss it.
In the RFC, I used a diagram and text to show how to use setup-vp in GitLab CI and the order of the steps.
The GitHub Actions code already existed, so at first it looked like we could reuse it.
But GitLab CI reads inputs and sets PATH in a different way, so that code does not work there.
So I kept the usage as similar as possible, and wrote steps only for GitLab.
Development continued after that. Now several CI services share the same install and authentication steps.
setup-vp also supports caching, and it uses the cache feature of both GitHub Actions and GitLab.
I did not build all of this myself.
After I added GitLab support, other members added more features.
A feature can grow from one PR as other people add to it. I think that is one of the interesting things about OSS.
Up to here, I showed things that I built. After I joined the team, I also started to investigate the causes of Issues.
Investigating a SolidStart preview failure
One example is an Issue where vp preview failed on SolidStart v2.
{% embed vite-plus#2416 %}
The error occurred when the user used Vite+, so at first it looked like a Vite+ problem.
But that was not enough to find the cause.
So I made two projects to test: one with Vite+, and one with Vite only.
- Reproduction with Vite+
- Reproduction with Vite only
The same error occurred with Vite only.
So I knew that the problem occurred without Vite+.
Then, was it a Vite problem? I still did not know.
The cause could be in SolidStart, so I read the stack trace to find where it failed.
I investigated more, and found that the cause was in the connection between SolidStart and Nitro.
Nitro is a tool that builds server applications.
Nitro writes the built server files to .output/server, but SolidStart looked for them in a different directory.
Because of this, SolidStart failed before Nitro's preview step started.
So I opened an Issue in the SolidStart repository, and shared the reproduction repositories and what I found.
{% embed solid-start#2291 %}
After that, the SolidStart team fixed the problem in PR #2294, and released the fix in version 2.0.1.
{% embed solid-start#2294 %}
@solidjs/start 2.0.1 release
I updated my projects and confirmed that the problem was gone.
In this case, I did not change any code.
But when someone reports a problem in Vite+, the correct fix is not always in Vite+.
I think finding the cause and taking it to the correct project is also a contribution to OSS.
As I showed, after I joined the team, I started to work on the project in many ways, and writing code was only one of them.
At first, I mostly fixed problems that I had myself.
For example, I thought that my first PR for vp create was done when the command showed that it did not find the template.
But after I joined the team and started to look at other people's Issues and PRs, I thought more before writing code.
In the SolidStart case, if I had changed Vite+ immediately, I could have changed code that was not the cause.
So now I investigate the problem first, and think about where the fix should go.
Before, other people reviewed my PRs. Now, I also think about other people's proposals together with them. That is the biggest change from my early days.
AI and OSS contributions
Up to here, I talked about investigating Issues and reviewing PRs.
I also use AI when I read code or implement changes.
It helped me most when I read code in a language that I did not know well.
But using AI for my own PRs is different from receiving PRs from other people as a team member.
Let me tell you what I learned from both sides.
Using AI to understand code
First, back to the Nushell work.
For Nushell, I used AI to read the Rust code.
When I saw a type or syntax that I did not know, I asked the AI what it meant.
I also asked it to make an HTML animation of the steps that the code runs.
In a language that you do not know, the syntax alone can stop you.
So getting an explanation at that moment helped me a lot.
But when you read an AI's explanation, you can feel that you understand when you do not.
In the Nushell example, even if I understood the Rust code, I still did not know if the generated source command worked.
So I ran it in Nushell, and checked the original code and the specification.
When you open a PR, a reviewer may ask why you wrote the code that way.
"Because the AI said so" is not an explanation.
So I check what the AI tells me, and I make sure that I can explain it in my own words.
Reviewing contributions made with AI
As a reviewer, I see a different side.
Now, implementation PRs sometimes arrive less than five minutes after someone opens an Issue.
A fast fix is good.
But for some Issues, the team has not yet decided whether to make the change.
When a PR arrives at that stage, the maintainers must check the code, and also decide whether the change is necessary at all.
Sometimes I ask a question in the review, and the author does not reply.
Then nobody can confirm the intent of the change, and the PR stops.
AI can make writing code faster.
But you still need time to understand that code and check that it works.
If you leave that work to the maintainers, you only move the work to them.
Understanding the problem before writing code
So I think you can also use AI for research and understanding before you write code.
For example, you find an open Issue on GitHub.
But an open Issue is not always waiting for an implementation.
The team may still be discussing the direction, or may not have decided whether to fix it at all.
So first, ask an AI to summarize the discussion in the Issue.
Then read the original comments too, and find out what the team has decided and what it has not.
If it is still not clear, tell the maintainers what you found, and ask them.
In the SolidStart Issue, I also shared the conditions that reproduce the problem and what I found, and asked about the direction of the fix.
With AI, writing code is much easier than before.
But opening a PR is not the goal. You must understand the problem, test the change yourself, and take responsibility for it.
So, before you ask AI to write code, use it to help you understand the problem.
I think this way of using AI is important for OSS contributions.
Conclusion
Today, I showed some of the Issues and PRs that I worked on.
At first, I only fixed a problem that I had with vp create. As I continued, I worked on migration, shells, CI, and more.
I did not know these areas well at the start.
I looked up what I did not know, tried it, opened a PR, and learned from the review. I did this again and again.
Over time, I learned the Vite+ code. I also learned what the project discusses and which direction it takes.
Now, what I learned then helps me when I look at other people's Issues and PRs.
Today I talked mostly about code. But you can contribute to OSS without writing code.
The SolidStart case is an example.
I reproduced the problem, found the cause, and shared it in an Issue. That was all.
Another person changed the code.
Also, if you try to reproduce a reported Issue on your machine, that helps.
If your comment includes your versions and the steps to reproduce the problem, it is easier to find the cause.
After a fix, a comment such as "I updated and it works now" also helps.
Fixing documentation, or telling the team what you think after you use a tool, is also a real contribution.
After I started to investigate Issues and review PRs myself, I saw how much these reports help.
Maybe you are interested in OSS, but you are not sure that you can help.
If so, start with one thing that you noticed in a tool that you use every day.
For example, when you have a problem, look on GitHub for the same Issue.
If you find it, try to reproduce it on your machine. If you find the conditions that cause it, write them in a comment.
That alone can help the maintainers who investigate the problem.
If you want to implement something, first read the Issue discussion and the contribution guide.
If the team has not decided the direction yet, tell them what you found and ask them.
Now AI can help you, so it is easier than before to read and understand code that you do not know.
I did not plan to join the Core Team.
I looked into a problem that I had when I used the tool, and I sent a fix. Because of that, I still work on Vite+ today.
Finally, let me tell you why I continue to contribute to OSS.
I look into a problem, change the code, and that makes a tool that I use better.
That is interesting.
But there is more. I can discuss the same project and review code with engineers that I would not meet at work.
These connections with people are a big reason why I continue with OSS.
It started when I fixed a problem that I had with a tool.
Now, I build Vite+ together with the people that I met there.
Behind the code of OSS, there are people who think and build together.
I want to continue to build OSS together with these people.
Thank you for listening.
Mentions
Contributing to Vite+ Inside Stories — Vue Fes Japan 2026 Speaker Notes This is the script of my talk "Contributing to Vite+ Inside Stories" at Vue Fes Japan 2026. I gave the talk in Japanese. This is an English translation, with links to the Issues and PRs that I talk about. {% embed docswell.com %} {% embed vuefes.jp %} Introduction Hello, everyone! My slides are in English, but I will speak in Japanese today, because I am still learning English. I hope you enjoy my talk! Today, I want to look back on the contributions that I made to Vite+. I will show the Issues and PRs that I worked on, and tell you what I was thinking at that time. This is not a difficult technical talk. It is a look back at what I did, so please relax and listen. At first, I worked on Vite+ as an individual contributor. After I joined the Core Team, my work changed. I started to investigate Issues and review PRs. Today, I will also talk about how my way of thinking about open source software (OSS) changed during that time. Let me introduce myself. My name is Naoki Haba. In my free time, I work on Vite+ every day as a Core Team member. What is Vite+? Before the main topic, let me introduce Vite+. Vite+ is a unified toolchain. It puts many tools for web development into one package. In daily development, you start a development server, run tests, and lint and format your code. To do this, you usually install many tools, and each tool has its own configuration and commands. Vite+ puts these tools together, so you can use all of them from one CLI, vp. You probably know many of the tools inside it. It uses Vite for the development server and application builds, Vitest for tests, Oxlint for linting, and Oxfmt for formatting. You run them with commands such as vp dev, vp test, and vp lint. vp pack builds libraries, and it uses tsdown. I will talk about tsdown again later, in the migration part. Now, let me tell you about my first contribution. My journey as a contributor My first contribution: vp create The first problem that I worked on was in vp create. vp create makes a new project from a template. When I used it, I typed the name of a template that did not exist. The command showed the pnpm 404 error as it was. With that error, it was hard to see what I did wrong. I looked on GitHub, and someone had already reported the same problem as an Issue. {% embed vite-plus#828 %} So I read the code and followed the steps that it ran. I found that the command ran the package manager without first checking if the package existed on npm. Because of this, when it did not find the template, it showed the pnpm error. This is the PR that fixed it. {% embed vite-plus#1055 %} Before it runs the package manager, the command now asks the npm registry if the package exists. If the registry returns 404, the command shows that it did not find the template, and then it stops. The message also tells you that vp create --list shows the available templates. This was my first PR to Vite+. It was a small change. But I read the real code and fixed a problem that I had when I used the tool. After that, I started to look at other Issues, a little at a time. Migrating Node.js version settings At about the same time, I wanted to use Vite+ at work. But existing projects already have a Node.js version setting and configuration for many tools. I wanted to know how to move those settings to Vite+. So I looked at vp migrate. This command migrates an existing project to Vite+. Rewriting configuration files sounds easy. But if the migration changes the Node.js version that the project uses, that is a problem. So I had to think about two things: how to read the old settings, and how to make the project work the same way after the migration. My first task here was to migrate the Node.js version setting. {% embed vite-plus#1158 %} Two files can set the Node.js version for a project: .nvmrc and .node-version. Vite+ uses .node-version, but projects that use nvm often have a .nvmrc file. So I changed vp migrate. When it finds .nvmrc, it migrates the file to .node-version. {% embed vite-plus#1159 %} For example, if the file contains a version number such as 20.11.0, the command copies that value. If the value starts with v, the command removes the v. Up to here, the command only cleans up the value and copies it. But .nvmrc can contain values that are not version numbers. I was not sure how to handle those values. For example, .nvmrc can contain node instead of a version number. node means "use the latest release of Node.js". lts/* means "use the latest LTS release". These two look similar, but they do not always give the same version. So, at first, when the file contained node, the command showed a warning and stopped the migration. If the command changed node to LTS without asking, the project could get an older Node.js version. I did not think that was correct. But when I opened the PR, a reviewer suggested that converting it to LTS might be fine. At about that time, I had also read an announcement. From Node.js 27, every major version moves to LTS after its release. {% embed nodejs.org %} Because of this, I changed the command to convert node to lts/* and continue the migration. But the new value does not mean the same thing as the old one, so the command writes a log message about the conversion. At first, I thought this task was only about copying the contents of a configuration file. But when I did it, I found cases where the command could not copy the old setting as it was. I gave priority to keeping the meaning of the old setting. The reviewer gave priority to letting the migration continue. Neither view was wrong. We had to decide which behavior was best for Vite+. Talking about the direction with other members, before and after writing code, is one thing that makes OSS contribution interesting for me. Up to here, I worked with Node.js, which I knew well. Next, I worked in a different area. Adding Nushell support That was support for Nushell. Nushell is a shell, like Bash or Zsh. You run commands in a terminal with it. Vite+ has a feature, vp env, that switches the Node.js version. The Issue asked to make this feature work in Nushell. {% embed vite-plus#1144 %} This part of Vite+ uses Rust. I had never used Rust in a real product before. So I started by reading the existing code for Bash and Fish, to learn what it did. I looked up the types and syntax that I did not know, and checked step by step how to do the same thing in Nushell. But reading the Rust code was not enough. I also had to learn about the Nushell script that the code generates. For example, look at this code: # Does not work source "$HOME/.vite-plus/env.nu" # Works source ~/.vite-plus/env.nu In the first example, the path that goes to source starts with $HOME. In Bash and similar shells, you often write the home directory like this. But in Nushell, $HOME inside double quotes does not expand. Also, Nushell writes environment variables as $env.HOME. So I thought that I only had to change that. But it still did not work. The reason is that Nushell's source decides which file to load when it parses the script, before any command runs. {% embed nushell.sh %} So you cannot use a runtime environment variable in that path. I read the Nushell documentation again, and changed the path to start with a tilde, as in the second example. With a tilde, Nushell can find the home directory when it parses the script. {% embed vite-plus#1312 %} The Rust code only makes a string. But I had to think about how Nushell reads that string. So I ran the script in Nushell to check each change. Before this, I had never written Rust code for a real product. I work as a frontend engineer, so I do not use Rust at work. I had solved some LeetCode problems in Rust, and that was all. When you study alone, you usually stay with what you already know. In OSS, you cannot do that. If you want to fix a problem, you must learn the language or the specification, even if you do not know it. In this case, I had to learn about Nushell as well as Rust. I did not understand everything at the start. I looked things up, tried them, got help in reviews, and learned a little at a time. It was good study for me, and it also helped a tool that I use. I think that is a very good deal. Joining the Core Team I continued like this. I investigated Issues that interested me, and I opened PRs. About one month after my first PR, the Vite+ Core Team invited me to join. I was very surprised. It was my first time on the core team of an OSS project. The members were engineers that I had looked up to for a long time. I never thought that I would work on the same team as them. After I joined the team, I started to look at Issues and PRs from other people, in addition to my own PRs. For example, when someone reports an Issue, I first try to reproduce it on my machine. If I can reproduce it, I look for the cause. If the report does not have enough information, I ask the reporter. I also review more PRs from other people. But the code alone does not always tell you why a change is necessary. So I read the related Issues and past discussions. When necessary, I also read the code of projects other than Vite+. Now I will show some of the work that I did as part of this. Migrating from tsdown to Vite+ The first one is a problem in the migration from tsdown to Vite+. tsdown is a tool that builds TypeScript libraries. Vite+ could already migrate projects from tsdown. But after the migration, some projects got TypeScript errors. {% embed vite-plus#1500 %} I investigated and found that references to the tsdown/client type definitions stayed in the project after the migration. So I added a matching export, vite-plus/pack/client, to Vite+, and made vp migrate rewrite the references. {% embed vite-plus#1501 %} But import statements were not the only place with these references. They were also in type declarations, in tsconfig.json, and in other places. {% embed vite-plus#1502 %} So I had to add a migration step for each of these formats. #1541 rewrites import and declare module statements. {% embed vite-plus#1541 %} #1542 rewrites compilerOptions.types in tsconfig.json. {% embed vite-plus#1542 %} Replacing a dependency sounds easy. But I had to make sure that TypeScript still worked after the migration. Supporting GitLab CI with setup-vp Next, let me talk about CI. If you use Vite+ at work, you want to use it in CI too, and not only on your machine. For this, I worked on setup-vp. setup-vp installs Vite+ in a CI environment, and sets up dependencies and caches. At that time, it supported GitHub Actions, but not GitLab CI. So, to use Vite+ on GitLab, you had to write the install steps yourself. {% embed setup-vp#88 %} I added a template, so that you do not have to write those steps yourself on GitLab CI. {% embed setup-vp#97 %} Now I am a collaborator on setup-vp, and I help to maintain it. For this work, I did not start by writing code. First, I wrote the design in an RFC. An RFC is a document that proposes a feature or a design, so that the team can discuss it. In the RFC, I used a diagram and text to show how to use setup-vp in GitLab CI and the order of the steps. The GitHub Actions code already existed, so at first it looked like we could reuse it. But GitLab CI reads inputs and sets PATH in a different way, so that code does not work there. So I kept the usage as similar as possible, and wrote steps only for GitLab. Development continued after that. Now several CI services share the same install and authentication steps. setup-vp also supports caching, and it uses the cache feature of both GitHub Actions and GitLab. I did not build all of this myself. After I added GitLab support, other members added more features. A feature can grow from one PR as other people add to it. I think that is one of the interesting things about OSS. Up to here, I showed things that I built. After I joined the team, I also started to investigate the causes of Issues. Investigating a SolidStart preview failure One example is an Issue where vp preview failed on SolidStart v2. {% embed vite-plus#2416 %} The error occurred when the user used Vite+, so at first it looked like a Vite+ problem. But that was not enough to find the cause. So I made two projects to test: one with Vite+, and one with Vite only. - Reproduction with Vite+ - Reproduction with Vite only The same error occurred with Vite only. So I knew that the problem occurred without Vite+. Then, was it a Vite problem? I still did not know. The cause could be in SolidStart, so I read the stack trace to find where it failed. I investigated more, and found that the cause was in the connection between SolidStart and Nitro. Nitro is a tool that builds server applications. Nitro writes the built server files to .output/server, but SolidStart looked for them in a different directory. Because of this, SolidStart failed before Nitro's preview step started. So I opened an Issue in the SolidStart repository, and shared the reproduction repositories and what I found. {% embed solid-start#2291 %} After that, the SolidStart team fixed the problem in PR #2294, and released the fix in version 2.0.1. {% embed solid-start#2294 %} @solidjs/start 2.0.1 release I updated my projects and confirmed that the problem was gone. In this case, I did not change any code. But when someone reports a problem in Vite+, the correct fix is not always in Vite+. I think finding the cause and taking it to the correct project is also a contribution to OSS. As I showed, after I joined the team, I started to work on the project in many ways, and writing code was only one of them. At first, I mostly fixed problems that I had myself. For example, I thought that my first PR for vp create was done when the command showed that it did not find the template. But after I joined the team and started to look at other people's Issues and PRs, I thought more before writing code. In the SolidStart case, if I had changed Vite+ immediately, I could have changed code that was not the cause. So now I investigate the problem first, and think about where the fix should go. Before, other people reviewed my PRs. Now, I also think about other people's proposals together with them. That is the biggest change from my early days. AI and OSS contributions Up to here, I talked about investigating Issues and reviewing PRs. I also use AI when I read code or implement changes. It helped me most when I read code in a language that I did not know well. But using AI for my own PRs is different from receiving PRs from other people as a team member. Let me tell you what I learned from both sides. Using AI to understand code First, back to the Nushell work. For Nushell, I used AI to read the Rust code. When I saw a type or syntax that I did not know, I asked the AI what it meant. I also asked it to make an HTML animation of the steps that the code runs. In a language that you do not know, the syntax alone can stop you. So getting an explanation at that moment helped me a lot. But when you read an AI's explanation, you can feel that you understand when you do not. In the Nushell example, even if I understood the Rust code, I still did not know if the generated source command worked. So I ran it in Nushell, and checked the original code and the specification. When you open a PR, a reviewer may ask why you wrote the code that way. "Because the AI said so" is not an explanation. So I check what the AI tells me, and I make sure that I can explain it in my own words. Reviewing contributions made with AI As a reviewer, I see a different side. Now, implementation PRs sometimes arrive less than five minutes after someone opens an Issue. A fast fix is good. But for some Issues, the team has not yet decided whether to make the change. When a PR arrives at that stage, the maintainers must check the code, and also decide whether the change is necessary at all. Sometimes I ask a question in the review, and the author does not reply. Then nobody can confirm the intent of the change, and the PR stops. AI can make writing code faster. But you still need time to understand that code and check that it works. If you leave that work to the maintainers, you only move the work to them. Understanding the problem before writing code So I think you can also use AI for research and understanding before you write code. For example, you find an open Issue on GitHub. But an open Issue is not always waiting for an implementation. The team may still be discussing the direction, or may not have decided whether to fix it at all. So first, ask an AI to summarize the discussion in the Issue. Then read the original comments too, and find out what the team has decided and what it has not. If it is still not clear, tell the maintainers what you found, and ask them. In the SolidStart Issue, I also shared the conditions that reproduce the problem and what I found, and asked about the direction of the fix. With AI, writing code is much easier than before. But opening a PR is not the goal. You must understand the problem, test the change yourself, and take responsibility for it. So, before you ask AI to write code, use it to help you understand the problem. I think this way of using AI is important for OSS contributions. Conclusion Today, I showed some of the Issues and PRs that I worked on. At first, I only fixed a problem that I had with vp create. As I continued, I worked on migration, shells, CI, and more. I did not know these areas well at the start. I looked up what I did not know, tried it, opened a PR, and learned from the review. I did this again and again. Over time, I learned the Vite+ code. I also learned what the project discusses and which direction it takes. Now, what I learned then helps me when I look at other people's Issues and PRs. Today I talked mostly about code. But you can contribute to OSS without writing code. The SolidStart case is an example. I reproduced the problem, found the cause, and shared it in an Issue. That was all. Another person changed the code. Also, if you try to reproduce a reported Issue on your machine, that helps. If your comment includes your versions and the steps to reproduce the problem, it is easier to find the cause. After a fix, a comment such as "I updated and it works now" also helps. Fixing documentation, or telling the team what you think after you use a tool, is also a real contribution. After I started to investigate Issues and review PRs myself, I saw how much these reports help. Maybe you are interested in OSS, but you are not sure that you can help. If so, start with one thing that you noticed in a tool that you use every day. For example, when you have a problem, look on GitHub for the same Issue. If you find it, try to reproduce it on your machine. If you find the conditions that cause it, write them in a comment. That alone can help the maintainers who investigate the problem. If you want to implement something, first read the Issue discussion and the contribution guide. If the team has not decided the direction yet, tell them what you found and ask them. Now AI can help you, so it is easier than before to read and understand code that you do not know. I did not plan to join the Core Team. I looked into a problem that I had when I used the tool, and I sent a fix. Because of that, I still work on Vite+ today. Finally, let me tell you why I continue to contribute to OSS. I look into a problem, change the code, and that makes a tool that I use better. That is interesting. But there is more. I can discuss the same project and review code with engineers that I would not meet at work. These connections with people are a big reason why I continue with OSS. It started when I fixed a problem that I had with a tool. Now, I build Vite+ together with the people that I met there. Behind the code of OSS, there are people who think and build together. I want to continue to build OSS together with these people. Thank you for listening.
Vue Fes Japan 2026 「 Vite+への貢献と、Team Memberになって見えてきた風景」スピーカーノート 導入 Hello, everyone! My slides are in English, but I will speak in Japanese today, since I am still learning English. I hope you enjoy my talk! みなさん、こんにちは。 今日は、私がこれまでVite+にどんなコントリビューションをしてきたのか、その内容を振り返りたいと思います。 具体的には、実際に取り組んだIssueやPRを紹介しながら、そのとき何を考えていたのか、という話です。 すごく難しい技術の話というよりは、自分が実際にやってきたことの振り返りなので、あまり身構えずに、気楽に聞いてもらえたらと思います。 また、最初は一人のコントリビューターとして関わっていたんですけど、Core Teamに参加してからは、Issueの調査やPRのレビューなど、関わり方も変わっていきました。 今日は、そうした中で、自分の考え方や、OSSに対する見方がどう変わったのかもお話しします。 軽く自己紹介をします。ハバ ナオキ（@naokihaba）と申します。 株式会社ANDPADという会社で、ソフトウェアエンジニアをしています。 趣味では、Vite+のCore Team Memberとして、日々開発に関わっています。 Vite+ とは では、本題に入る前に、Vite+について簡単に紹介します。 Vite+は、Web開発で使うさまざまなツールを、一つにまとめた統合ツールチェーンです。 普段の開発では、開発サーバーを起動したり、テストを実行したり、Lintやフォーマットをしたりしますよね。 そのために、いくつものツールをインストールして、それぞれの設定やコマンドを使い分けていると思います。 Vite+では、こうしたツールをまとめて、vp という一つのCLIから使えるようにしています。 中で使っているツールは、皆さんも知っているものが多いと思います。 開発サーバーやアプリケーションのビルドにはVite、テストにはVitest、LintにはOxlint、フォーマットにはOxfmtを使っています。 これらを、vp devやvp test、vp lintといったコマンドで実行できます。 あとは、ライブラリをビルドするvp packでは、tsdownを使っています。これは、あとで移行の話にも出てきます。 こんなふうに、いろんなツールを一つのCLIから使えるのがVite+です。 では、ここから私が最初にコントリビュートしたときの話をします。 コントリビューターとしての軌跡 私が最初に取り組んだのは、vp createで起きていた問題です。 vp createは、テンプレートを使って新しいプロジェクトを作るコマンドです。 これを自分で使っていたときに、存在しないテンプレート名を指定したら、pnpmの404エラーがそのまま表示されたんですね。 これだと、何を間違えたのか、ちょっとわかりにくいなと思いました。 そこでGitHubを見てみると、同じ問題がIssueとして報告されていました。 vite-plus#828 じゃあ、ちょっとコードを読んでみようと思って、処理を追っていきました。 すると、npmにパッケージが存在するか確認せずに、そのままパッケージマネージャーを実行していたんです。 そのため、テンプレートが見つからない場合も、pnpmのエラーがそのまま表示されていました。 そこで修正したのが、こちらのPRです。 vite-plus#1055 パッケージマネージャーを実行する前に、npmレジストリに問い合わせて、パッケージが存在するか確認するようにしました。 もし404が返ってきたら、テンプレートが見つからなかったことを表示して、処理を止めます。 あわせて、vp create --listで使えるテンプレートを確認できることも案内しています。 これが、Vite+に出した最初のPRでした。 大きな変更ではないんですけど、自分が使っていて困ったところを、実際にコードを読んで直せたんですね。 それがきっかけで、ほかにはどんなIssueがあるんだろうと、少しずつ見るようになりました。 ちょうどこの頃、仕事でもVite+を使ってみたいなと思っていました。 ただ、既存のプロジェクトには、すでにNode.jsのバージョン指定や、いろんなツールの設定がありますよね。 それをVite+に移すとき、どうすればいいんだろう、というのが気になっていました。 そこで見ていたのが、vp migrateです。 これは、既存のプロジェクトをVite+に移行するためのコマンドです。 ただ設定ファイルを書き換えるだけなら簡単そうなんですけど、移行したことで使うNode.jsのバージョンが変わってしまったら、困りますよね。 なので、元の設定をどう読み取るかだけでなく、移行したあとも同じように動くかを考える必要がありました。 そこで最初に取り組んだのが、Node.jsのバージョン設定の移行です。 vite-plus#1158 ここで出てくるのが、.nvmrcと.node-versionです。 どちらも、プロジェクトで使うNode.jsのバージョンを指定するためのファイルです。 Vite+では.node-versionを使うんですが、nvmを使っているプロジェクトには、.nvmrcが置かれていることがあります。 そこで、vp migrateで.nvmrcを見つけたら、.node-versionに移行できるようにしました。 vite-plus#1159 例えば、20.11.0のようにバージョン番号が書いてあれば、その値を移します。 先頭にvが付いていれば、それを取り除く、という感じです。 ここまでは、ちょっと整えてコピーするだけなんですけど、実は.nvmrcには、バージョン番号以外も書けるんですよね。 その指定をどう扱うか、というところで少し悩みました。 例えば、.nvmrcには、バージョン番号の代わりにnodeと書くことができます。 これは、Node.jsの最新リリースを使う、という指定です。 一方、lts/*と書くと、最新のLTSを使う指定になります。 この2つ、似ているんですけど、必ずしも同じバージョンにはならないんですよね。 なので、最初はnodeが指定されていたら、警告を出して移行を止めるようにしていました。 勝手にLTSに変換すると、使うNode.jsのバージョンが下がってしまう可能性があるので、それはちょっと違うかなと思ったんです。 ただ、PRを出したところ、レビューで「LTSに変換してもいいんじゃないか」という提案をもらいました。 vite-plus#1159 ちょうどその頃、Node.js 27以降は、すべてのメジャーバージョンがリリース後にLTSへ移行する、という発表も読んでいました。 nodejs.org そうしたことも踏まえて、最終的にはlts/*に変換して、移行を進める形にしました。 ただし、元の指定とは意味が変わるので、変換したことはログに出すようにしています。 この対応、最初は設定ファイルの中身を移すだけだと思っていたんですよね。 でも実際にやってみると、元の設定をそのまま移せないケースがありました。 今回も、私は元の設定の意味を変えないことを優先していたんですけど、レビューでは、移行を進められるようにするという別の考え方をもらいました。 どちらが正しいというより、Vite+としてどういう動作にするのがいいのか、考える必要があったんですね。 こういうふうに、コードを書く前後で、ほかのメンバーと方針を相談することも、OSSへの貢献の面白いところだなと思いました。 ここまでは、普段から馴染みのあるNode.js周りの話だったんですけど、次は少し違う領域に取り組んだ話です。 それが、Nushellのサポートです。 Nushellは、BashやZshと同じように、ターミナルでコマンドを実行するためのシェルです。 Vite+には、Node.jsのバージョンを切り替えるvp envという機能があって、これをNushellでも使えるようにする、というIssueでした。 vite-plus#1144 この部分はRustで書かれていたんですが、実際のプロダクトでRustを使うのは初めてでした。 なので、まずは既存のBashやFish向けの実装を読んで、どういう処理をしているのか調べるところから始めました。 わからない型や構文を調べながら、同じことをNushellではどう書けばいいのか、少しずつ確認していきました。 ただ、Rustのコードが読めれば終わりではなくて、出力するNushellのスクリプトについても調べる必要がありました。 例えば、こちらのコードです。 動かない source "$HOME/.vite-plus/env.nu" 動く source ~/.vite-plus/env.nu 上の例では、sourceに、$HOMEから始まるパスを渡しています。 Bashなどでは、ホームディレクトリを指定するときに、こういう書き方をしますよね。 ただ、Nushellでは、ダブルクォートの中の$HOMEは展開されません。環境変数の書き方も、$env.HOMEになります。 じゃあ、そこを書き換えればいいのかと思ったんですけど、実はそれでも動かなかったんですよね。 というのも、Nushellのsourceは、コマンドを実行する前の、解析の段階で読み込むファイルを決める仕組みになっています。 nushell.sh なので、実行時の環境変数を、そのままパスに使うことができません。 そこからNushellの仕様を調べ直して、下の例のように、チルダから始まるパスに修正しました。 これなら、解析の段階でホームディレクトリへのパスを解決できます。 vite-plus#1312 Rust側では文字列を作っているだけなんですけど、それがNushellでどう解釈されるかまで考えないといけなかったんですね。 なので、実際にNushellで動かしながら、確認していきました。 そもそも、Rustで実際のプロダクトのコードを書いた経験は、これまでありませんでした。 普段はフロントエンドエンジニアとして働いているので、仕事でRustを使う機会もないんですよね。 LeetCodeの問題をRustで解いたりはしていたんですけど、それくらいでした。 自分で勉強しているだけだと、どうしても知っている範囲でやりがちなんですけど、OSSだとそうはいきません。 直したい問題があれば、知らない言語や仕様でも、調べる必要があります。 今回も、Rustだけでなく、Nushellの仕様まで調べることになりました。 最初から全部わかっていたわけではなくて、調べて、試して、レビューで教えてもらって、少しずつ理解していった感じです。 それが自分の勉強にもなって、使っているツールへの貢献にもなるので、結構お得なんじゃないかなと思っています。 Core Team に入って そんな感じで、気になったIssueを調べたり、PRを出したりしていました。 そうしていたら、最初のPRから約1か月後に、Vite+のCore Teamに招待してもらったんですね。 これは、本当に驚きました。 OSSのCore Teamに参加するのは初めてでしたし、そこにいるのは、自分にとって雲の上の存在のようなエンジニアばかりだったので。 まさか自分が同じチームで開発することになるとは、思っていませんでした。 チームに入ってからは、自分でPRを出すだけでなく、ほかの人のIssueやPRも見るようになりました。 例えば、Issueが報告されたら、まず自分の環境でも再現するか試してみます。 再現できたら原因を調べたり、情報が足りなければ報告してくれた人に確認したりしています。 あとは、ほかの人のPRをレビューすることも増えました。 ただ、コードを見ただけでは、なぜその変更が必要なのかわからないこともあるんですよね。 なので、関連するIssueや過去のやり取りを読んだり、必要に応じてVite+以外のプロジェクトのコードまで調べたりしています。 ここからは、そうした活動の中で取り組んできたものを、いくつか紹介します。 まず紹介するのは、tsdownからVite+への移行で起きていた問題です。 tsdownは、TypeScriptのライブラリをビルドするためのツールです。 Vite+では、tsdownから移行できるようになっていたんですが、移行したあとにTypeScriptのエラーが出るケースがありました。 vite-plus#1500 調べてみると、tsdown/clientという型定義への参照が、移行後も残っていたんですね。 そこで、Vite+側に対応する参照先を用意して、vp migrateでも自動的に書き換えるようにしました。 vite-plus#1501 ただ、この参照はソースコードのimportだけでなく、型宣言やtsconfig.jsonなど、いろんな場所で使われていました。 vite-plus#1502 なので、それぞれの書き方に合わせて、移行処理を追加する必要がありました。 #1541 はimportとdeclare moduleを書き換えます。 #1542 はtsconfig.jsonのcompilerOptions.typesを書き換えます。 依存関係を置き換えるだけなら簡単そうなんですけど、実際には、移行したあともTypeScriptが正しく動くところまで考える必要があったんですね。 次は、CIの話です。 仕事でVite+を導入するなら、手元で動くだけではなく、CIでも使いたいですよね。 そこで取り組んだのが、setup-vpというツールです。 これは、CI環境にVite+をインストールしたり、依存関係やキャッシュを設定したりするためのツールです。 当時はGitHub Actionsには対応していたんですが、GitLab CIには対応していませんでした。 なので、GitLabでVite+を使おうとすると、インストール処理などを自分で書く必要があったんですね。 setup-vp#88 そこで、GitLab CIでも簡単にVite+を使えるように、テンプレートを追加しました。 setup-vp#97 今は私もsetup-vpのコラボレーターとして、継続的にメンテナンスに参加しています。 この対応では、いきなりコードを書き始めたわけではなくて、まず設計をRFCにまとめました。 github.com/voidzero-dev/setup-vp/blob/main/rfcs/g… RFCというのは、機能や設計の方針を提案して、ほかのメンバーと議論するための文書です。 今回は、GitLab CIでどう使うのか、どんな順番で処理するのかを、図と文章にまとめました。 GitHub Actions向けの実装がすでにあったので、最初はそれを流用すればよさそうに見えます。 ただ、GitLab CIでは、入力の受け取り方やPATHの設定方法などが違うので、そのままでは動きません。 そこで、使い方はできるだけ揃えつつ、GitLab向けの処理を用意しました。 その後も開発は続いていて、今ではインストールや認証などの処理を、複数のCIで共有する構成になっています。 キャッシュにも対応していて、GitHub ActionsとGitLab、それぞれのキャッシュ機能を使えるようになっています。 もちろん、今の構成を全部自分で作ったわけではありません。 私がGitLab対応を追加したあと、ほかのメンバーも機能を追加してくれました。 こうやって、一つのPRをきっかけに、ほかの人と一緒に機能が育っていくのも、OSSの面白いところだと思っています。 ここまでは、自分で実装したものを紹介してきましたが、チームに入ってからは、Issueの原因調査にも関わるようになりました。 その一つが、SolidStart v2でvp previewが失敗するというIssueです。 vite-plus#2416 Vite+を使っていてエラーが出ているので、最初はVite+側に問題があるようにも見えますよね。 ただ、これだけでは、どこが原因なのかはわかりません。 そこで、Vite+を使うプロジェクトと、Viteだけを使うプロジェクトの、2つを用意して試してみました。 Vite+で再現したリポジトリ Viteだけで再現したリポジトリ すると、Viteだけでも、同じエラーが出たんです。 つまり、少なくともVite+を使わなくても、問題が起きることはわかりました。 じゃあViteの問題なのかというと、それもまだわかりません。 SolidStart側の処理かもしれないので、スタックトレースを見ながら、どこで失敗しているのかを調べていきました。 さらに調べていくと、原因はSolidStartとNitroの連携部分にありました。 Nitroは、サーバー側のアプリケーションをビルドするためのツールです。 ビルドしたサーバーファイルを.output/serverに出力するんですが、SolidStart側では、別の場所を探していたんですね。 そのため、Nitroのpreview処理に進む前に、SolidStart側でエラーになっていました。 そこで、SolidStartのリポジトリにIssueを立てて、再現用のリポジトリと、調査した内容を共有しました。 solid-start#2291 その後、SolidStart側で修正してもらい、修正が含まれたバージョン2.0.1がリリースされました。 修正PR #2294 @solidjs/start 2.0.1 のリリース 自分でも更新してみて、問題が解消されたことを確認しています。 この対応では、私はコードを修正していません。 ただ、Vite+で報告された問題でも、Vite+で直すのが正しいとは限らないんですよね。 原因を調べて、適切なプロジェクトにつなぐことも、OSSへの貢献の一つだと思っています。 ここまで紹介してきたように、チームに入ってからは、自分でコードを書く以外にも、いろんな形でプロジェクトに関わるようになりました。 最初の頃は、自分が困っていた問題を直すことが中心でした。 例えば、最初のvp createのPRも、テンプレートが見つからないことを、わかりやすく表示できれば解決でした。 ただ、チームに入って、ほかの人のIssueやPRを見るようになると、コードを書く前に考えることが増えました。 SolidStartの件も、いきなりVite+側を修正していたら、原因とは違うところを触っていたかもしれません。 なので、まずは問題を調べて、どこで対応するのが正しいのかを考えるようになりました。 自分のPRをレビューしてもらう側から、ほかの人の提案についても、一緒に考える側になった。 そこが、最初の頃と大きく変わったところだと思っています。 AI と OSS への貢献 ここまで、Issueの調査やPRのレビューについて話してきました。 こうしたコードを読んだり、実装を進めたりするときには、私もAIを使っています。 特に、慣れていない言語を読むときには、かなり助けられました。 ただ、自分でAIを使ってPRを出すときと、チームでほかの人のPRを受け取るときでは、少し違うことも感じています。 ここからは、その両方の視点で感じたことを紹介します。 まずは、先ほどのNushell対応の話です。 Nushellの対応では、Rustのコードを読むためにAIを使っていました。 この型は何なのかとか、この構文はどういう意味なのかを、その都度聞いていました。 処理の流れを、HTMLのアニメーションにしてもらったこともあります。 慣れていない言語だと、構文がわからないだけで、なかなか先に進めないんですよね。 なので、その場で説明してもらえるのは、かなり助かりました。 ただ、AIの説明を読むと、なんとなくわかった気にもなるんです。 先ほどのNushellの例でも、Rust側の処理が理解できたとしても、出力されたsourceのコマンドが実際に動くかは、別の話です。 なので、実際にNushellで動かしたり、元のコードや仕様を調べたりして確認していました。 PRを出すと、レビューで、なぜこう書いたのかを聞かれることもあります。 そこで「AIがそう言っていたので」と答えても、説明にはならないですよね。 だからこそ、AIに教えてもらったことも、自分で確認して、自分の言葉で説明できるようにしています。 一方で、PRをレビューする側になって、感じることもあります。 最近は、Issueが立ってから5分もしないうちに、実装のPRが届くこともあるんですよね。 もちろん、早く修正してもらえるのはありがたいです。 ただ、Issueによっては、まだ対応するかどうかも決まっていないことがあります。 そこにPRが届くと、コードを確認するだけでなく、そもそもこの変更が必要なのか、というところから考える必要があります。 レビューで質問を返しても、返信がなくなってしまうこともあります。 そうなると、変更の意図を確認できないまま、PRが止まってしまいます。 AIを使えば、コードを書く時間は短くできます。 でも、そのコードを理解して、正しく動くか検証する時間まで、なくなるわけではありません。 そこをメンテナーに任せてしまうと、単に負担を移している だけになってしまうんですよね。 なので、AIを使うなら、コードを書く前の調査や理解にも使えるんじゃないかな、と思っています。 例えば、GitHubでOpenになっているIssueを見つけたとします。 でも、Openだからといって、必ずしも実装を待っているわけではありません。 まだ方針を議論していることもありますし、そもそも対応するかどうかも決まっていないかもしれません。 そこで、まずはIssueのやり取りをAIに整理してもらう。 元のコメントも確認しながら、何が決まっていて、何がまだ決まっていないのかを理解する、という使い方です。 それでもわからなければ、自分で調べたことを添えて、メンテナーに相談してみればいいと思います。 私もSolidStartのIssueでは、再現する条件や調査した内容を共有して、修正の方向性を相談しました。 AIを使えば、コードを書くこと自体は、以前よりずっと簡単になっています。 でも、大切なのはPRを出すこと自体ではなくて、問題を理解して、自分で検証し、その変更に責任を持つことだと思っています。 なので、いきなりコードを書いてもらうだけではなく、問題を理解するところからAIに手伝ってもらう。 そういう使い方も、OSSへの貢献では大切なんじゃないかなと思っています。 おわりに ここまで、私が取り組んできたIssueやPRを、いくつか紹介してきました。 最初は、vp createで自分が困ったところを直しただけだったんですけど、続けているうちに、移行処理やシェル、CIなど、いろんなところに関わるようになりました。 もちろん、どれも最初から詳しかったわけではありません。 わからないところを調べて、実際に試して、PRを出して、レビューでまた教えてもらう。その繰り返しでした。 そうしているうちに、Vite+のコードだけでなく、プロジェクトの中でどんな議論があって、どういう方針で開発されているのかも、少しずつわかるようになってきました。 今、ほかの人のIssueやPRを見るときにも、そのときに調べたことが役に立っています。 ここまで、コードの話を中心にしてきたんですけど、実は、コードを書かなくてもOSSに貢献できることはあります。 例えば、先ほどのSolidStartの件です。 私がやったのは、問題を再現して、原因を調べて、その内容をIssueで共有するところまででした。 実際のコードの修正は、別の人が進めてくれました。 ほかにも、Issueで報告された問題が、自分の環境でも再現するか試してみるだけでも助かります。 そのときに、使っているバージョンや再現手順が書いてあると、原因を調べやすくなるんですよね。 逆に、修正されたあとに「更新したら直りました」と報告してもらえるのも、ありがたいです。 あとは、ドキュメントを直したり、使ってみた感想を伝えたりすることも、立派な貢献だと思っています。 自分がIssueを調べたり、PRをレビューしたりするようになって、こういう報告のありがたさを実感するようになりました。 OSSに興味はあるけれど、自分にできることなんてあるのかな、と思っている方もいるかもしれません。 そういう方は、まず普段使っているツールで、気になったことを一つ調べてみるのがいいと思います。 例えば、何か問題に遭遇したら、GitHubで同じIssueがないか探してみる。 見つかったら、自分の環境でも再現するか試してみる。再現する条件がわかったら、それをコメントしてみる。 それだけでも、問題を調べているメンテナーにとっては、助けになることがあります。 もし実装してみたいものがあれば、まずはIssueのやり取りや、コントリビューションガイドを読んでみてください。 まだ方針が決まっていなければ、調べたことを伝えて、相談してみるのもいいと思います。 今はAIにも手伝ってもらえるので、知らないコードを調べたり、理解したりすることも、以前より取り組みやすくなっています。 私自身も、最初からCore Teamに入ろうと思っていたわけではありません。 自分が使っていて困ったところを調べて、修正を出した。それがきっかけで、今もVite+の開発に関わっています。 最後に、私がなぜOSSへの貢献を続けているのか、という話をしたいと思います。 自分が気になった問題を調べて、実際にコードを修正して、それが使っているツールの改善につながる。 それ自体も、もちろん面白いです。 でも、それだけではなくて、普段の仕事では関わる機会のないエンジニアと、同じプロジェクトについて議論したり、お互いのコードをレビューしたりできる。 そういう人とのつながりも、OSSを続けている大きな理由です。 最初は、自分が使っていて困ったところを直すことから始まりました。 今は、そこで出会った人たちと、一緒にVite+を作っています。 （ここから1番伝えたいところ） OSSは、コードだけではありません。 その先には、一緒に考えたり、作ったりする人たちがいます。 これからも、そんな人たちと一緒に、OSSを作っていきたいと思います。 ご清聴ありがとうございました。
@jroosdot @steipete @solid_js The original is on our Solid 2 branch: github.com/solidjs/solid/blob/next/packages/solid…
@g2sans @RyanCarniato @theo @t3dotchat github.com/solidjs/solid/tree/next/documentation I haven't studied their server components for a precise critique, but get the feeling it's overcomplicating stuff.
@RyanCarniato @theo @t3dotchat github.com/solidjs/solid/tree/next/examples/chat-… I still see though that you guys are trying, this is good! But this is what I mean when I say that you guys are constrained by the tooling that you use The `getThread` is a `liveQuery` that accepts a `live` that accetps a `GET` server function that emits JSX, that a `dynamicComponent` renders into a HOC that accepts callbacks. This is by no means simple. I have absolutely no idea what any of this is doing under the hood, it feels like I need a phd on front end. Too much abstraction for an idea that is fundamentally simple, building an html string to the browser.