preface
Why should an ambitious front-end try to integrate into the open source community?
Because there are tons of treasures hidden within the open source community, real treasures!
The latest tools! Grasp the trend! Witness how the big guy unravels complex problems! See how famous teams make choices between dilemmas! Difficult problem solving skills, circuitous compatible artful! Too much! Are the daily work rarely have the opportunity to face, let alone discuss with people. But in the open source community, You can ask Evan You questions, You can contribute code to Iamkun, You can do a job with more people than You; So, yes. No question, we — opt in!
Step 1: How to filter the warehouse?
To join the community, but where should we start? My advice is to start with 1 or 2 libraries that you use most often in your work/study and are not particularly stable, preferably alpha or beta versions.
- A lot. It means you’ll understand it better, and it’ll be easier to spot problems.
- The version is not stable yet. That means more problems and easier fixes. (This is very important for a newcomer)
- Star is more. Star more means that the library has some influence, is used by many people, it is easier to find problems;
- Frequent maintenance. Frequent maintenance means that your PR will be processed in a short period of time, which is important for maintenance
enthusiasm
Is very important.
Taking my personal situation as an example, my current main technology stack is vue3. X, together with Element Plus, Vite, vite-Press, etc. Based on the comprehensive consideration mentioned above, I will choose this library as the main goal of my recent study:
- Element Plus (version 1.2.0- Beta-.5)
- Vitepress (Version: 0.20.2)
Both of these libraries are pretty much in line with the points I’ve listed above.
ไปฅ Element Plus
For example:
12.8 K Star
(Super likes)2.2 K Fork
(Being pulled to their own warehouse by 2.2k people)236K+
Download /Month (230,000 times per Month + Download)300 +
Open Issues (at least 300 ongoing Issues that have not been closed)90 +
Open PullRequest (90+ merge requests that have not yet been merged)170 +
Commit Last Month (170+ commits in the Last Month)- Famous UI library
ElementUI 2.x
็The orthodox sequel
Don’t worry professionally, I can learn more things and norms. - Every day I
Eight hours
It makes it easier to spot problems.
Personally, this is definitely one of the best libraries I’ve ever tried to contribute to. With that in mind, what’s the best library to try? If it is Element Plus, it is also too fate, can communicate more ๐๐.
Step 2: How to find change points?
In general, modification points come from two sources:
- In the warehouse
A list of issues
Find questions that are right for you. - Your own problems in the process of use.
A. how toA list of issues
For the problem?
Issues can be translated as Issues. It is often used for asking for help, reporting problems, finding new features, etc.
Find your own issues in the project list, not aimlessly by luck. But with skill!
First, filter the Open state problem.
An Issue can be either Open or Closed.
A Closed issue has either been officially judged as an invalid issue or has been resolved. Therefore, it is perfectly acceptable for us to keep the following filters in the search box of the Issue list page throughout the year:
is:open
Copy the code
Second, learn to filter by Label.
Label refers to Label. Usually, the maintainer of open source library will Label different types of problems with different labels to facilitate management.
In order toElement Plus
For example, it has 72 different kinds ofLabel
:
Some indicate the type of issue, some indicate the component involved, some indicate it comes from community contributions, and so on. But the most important ones are these two tags:
- PR Welcome (Submit PR)
- Good for new contributor
So, we can just pick one of them and start ourissue
A journey of discovery.
And you filter it like this. ๐ผ ๐ผ
Then, find a problem that you think about.
Don’t be afraid of English, use browser translation or translation plugin! If your English is great, forget it.
After 5 minutesIn English and in combination with
In my search, I focused on one question:
“Cascade component: Please add an option to make filtering (search) case insensitive.”
I confirmed the look. It’s in my power.
Click in, after judging the Label, this Issue welcomes to submit PR and has Feature Request.
Therefore, we can be bold to develop!
Ok, with this as an example, we saw how to find a problem that suits us through the issue list.
b. Their discoveryWhat about the problem of…?
If you find a problem, don’t mention PR! Search the issue list first!
A certain question. You areThe first discoverer
The probability is actually not large, so for us ordinary developers, most of the problems encountered, should be inissue
Find the answer in the list.
If you went throughissue
I can’t find anyone on my list. Congratulations! You’ve discovered a new problem!
If you do your research and find that you can solve the problem, that’s great. But I recommend you build one firstissue
Describe your problem and tackle it laterissue
.
In this way, latecomers can find that the problem has been solved and record and track the problem in more detail.Note: when raising an ISSUE, please not only follow the specifications of the warehouse, but also provide itMinimum reproducible instance
.
Jsfiddle, Codepen, and CodesandBox are excellent minimal-reproducible instance tools.
For example:
When I was at work the other day, I found that when the column with show-overflow-tooltip attribute was set to “light” in el-Table, when the text was too long, the popup tool-tip style was 1px wrong.
Long like this:
After a cursory look at the source code, I immediately realized: THIS bug I can fix!
Therefore, I created an issue in my spare time and submitted a Pull Request to solve the issue.
So?
What is a Pull Request? How should I submit it? Read on.
Step 3: How do I fork the warehouse?
Before making any code changes, we need to take a lookgithub
The basic pattern for open source repository code submission:fork => Pull Request
Mode.
Typically, you contribute your code to an open source repositoryelement-plus
As an example) :
Fork
!
Fork code from the element-Plus main repository to your home page’s XXX/Element-Plus repository. (It’s understandable to copy the same code from Element-Plus.)
Commit
!
Fix bugs in your own repository and commit to your XXX/Element-Plus repository.
PR
!
Initiate a Pull Request to the Element-Plus main warehouse and apply for membership. (Select your own COMMIT and send it to the maintainer of the main repository, telling them that you expect your code to be incorporated into the main repository.)
NICE
!
Your code is plugged in and waiting for release.
From a contributor’s point of view, contributing code simply follows the steps above.
So, how do we fork the code? It’s easy. One click.
Yeah, all you have to do isThe main warehouse
Click on the upper right corner of the mouse, you can finishfork
!
Soon, there will be a warehouse on your homepage:
That’s right, this is where you successfully fork to the repository and then your codeSubmission and Push, all need to be done in this warehouse.
Step 4: How to find the debug method for the warehouse?
When it comes to fixing bugs, debugging must be part of the equation, because we’re only human.
However, a lot of the code we contribute is not apps, but more likely some libraries that provide capabilities, such as: UI libraries, debugging tools, scripts, etc… As a result, we must figure out how to debug efficiently.
Method 1: LookContribute.md
Most repositories have contribution guidelines for contributors, with names ranging from CONTRIBUTE. Md to dev. md to dev_FAq.md. Usually this document tells you how to “start the project” and “how to debug the project”. Take Element-Plus, whose developer’s guide is called dev_FAq.md. And introduces three things in this.md file:
- use
pnpm i
Install dependencies - use
pnpm link
Way to debug - Don’t be in
theme
็scss
Write Chinese notes in the file.
An exhaustive guide to the “developer’s Guide” is a lottery, and we have to learn the skills of the project from other sources, so how do we do that?
Method 2: Lookpackage.json
In thescripts
As we all know, the scripts in the package.json front-end project are usually the control center for various scripts throughout the project. Contains but is not limited to: COMMIT specifications, debug commands, build commands, document builds, version upgrades… Wait, all kinds of capabilities converge here.
If you know scripts, you know exactly what a project can do during development.
In order toelement-plus
For example, let’s take a quick look at itsscripts
!!!!
After a quick scan, we found a script that might be useful for debugging:
pnpm run dev
Copy the code
Execute the above command to quickly start a 3000 port service that, when opened, will find several element-Plus components loaded.
The entry to this debug page is here:
play/main.ts
Copy the code
Step 5: Write code and fix bugs!
This is a section that I wanted to skip. After all,
Change the bug! Who wouldn’t know that?
All right, that’s the end of the joke.
This is what I changedissue
# 4697As an example.
To fix this bug, I did one thing altogether:
๐๐ yes, it was just one line of code.
Step 6: Submit the code according to the specification
I’m going to assume that you’ve completely “fixed the bug” or” implemented the feature “.
So, how do YOU submit code?
1. Enter a value manuallycommit-msg
Different projects often have different requirements in terms of details. Commit specifications, however, generally require Conventionalcommits. # Conventionalcommits Description of Conventionalcommits:
# Category scope of influence: Brief description
<type>[optional scope]: <description>
# Detailed description
[optional body]
# Some related information, such as related issue
[optional footer(s)]
Copy the code
Here’s an example:
# Category + simple description
feat: allow provided config object to extend other configs
# Category + simple description + Incompatible update declaration (exclamation mark)feat! : send an email to the customer when a product is shipped# Category + simple description + Incompatible update declaration (exclamation mark) + Scope of impact (contents in parentheses)feat(api)! : send an email to the customer when a product is shippedCopy the code
For more detailed description, you can click on the link above for more detailed study. There is no more introduction here.
2. Use the tool for interactive submission
This scenario is not an alternative to scenario 1, but rather a COMMIT specification mandated by some repositories!
Those of you who are familiar with the open source community may find that more and more open source projects are startingDirectly or indirectly
There’s a dependency calledcommitizen
(# address)npm
Package or its indirect products.
Such as:element-plus
ๅ yarn
I just used it
The purpose of this tool is to “interactively” regulate your submission record.
Ok, with that in mind, we can “interactively” start committing our commit-msg.
Taking the submission process of Element-Plus as an example, the specific process is as follows:
yarn cz
? Select the type of change that you're committing: Select an appropriate category based on your submission. For example, if you fix a bug, move the cursor to Fix > Fix? What is the scope of this change (e.g. component or file name): # What is the scope of your change? For example, if you modify a component, type: Components > Components? Write a short, imperative tense description of the change (Max 83 Chars): # Please Write a short, imperative tense description of the change. Let the table support deformation; Fix # 0001; # Take the above "delete a line of code" fix #4697? Provide a longer description of the change: (press enter to skip) # Provide a detailed description of the change # Are there any breaking changes? Are there incompatible changes? # N no /Y yes? Does this change affect any open issues? Is there any relevant issue in open state? # a little Y, no NCopy the code
Some file format specification is then triggered, and your commit succeeds.
The advantage of this is that the elemental-Plus official can then generate each version of CHANGELOG through a COMMIT record.
Step 7: Pass all unit tests
In fact, in theory, this step is better written before commit, after all, you don’t run test cases after the code changes, it’s a bit overconfident.
If your changes are bug-fix, you usually won’t have a problem as long as you pass the YARN test normally.
But if your changes are new features, you may have to add some use cases yourself.
For example, you add the following features:
Added a prop that, when true, makes the button rainbow colored.
You’ll need to add a test case to make sure that when it’s true, it’s actually rainbow color, otherwise if someone adds a feature or fixes a bug that disables your button’s rainbow color function, no one will notice until the release.
This can lead directly to certain features being severely impacted in a production environment.
Therefore, running use cases and writing use cases is a must for everyone who wants to participate in open source.
Step 8: Submit PR!
8.1 Push code to youfork
Go to the branch that came out
# Suppose you fix a bug on the fix-4697 branch
git push origin fix-4697
Copy the code
8.2 generate PR
In yourfork
Out of the project, openPull Request
TAB, and then click on the green one on the far rightNew Pull Request
Button.
Browse yourmerge
Make sure they are exactly what you want to submit.
Step 9: Wait for good news
When your PR is created, don’t worry, you may just have to wait.
You may suddenly receive a github in-app message that your PR has been successfully incorporated, which means that from this point on, you have become a contributor to the open source repository.
Click in the Insight TAB in the main warehouse and start trying to find your name!
By now, you may be a contributor to the open source repository.