:::

改善別人做好的輪子!從原始套件建立自己的NPM私領域套件 / How to create a NPM Scoped Package from an Original Pacakge?

6-NPM_How_to_Fork_an_Existed_NPM_Package.png

Node.js上開發專案的好處就是可以透過npm找到大量好用的套件。但有時候,你可能會發現某些套件的內容不合你的需求,或是程式運作上有錯誤。也許你可以到問題討論版(issues)提出修改請求、苦苦等待作者的回應,不過其實你也可以在授權條款允許的情況下,自行取得別人的程式碼,並以私領域套件(scoped pacakge)的形式發佈到npm註冊處。來看看這要怎麼做吧。


關於套件 / Package

dT9rkge9c.jpg

(圖片來源:Clipart Library)

所謂的「套件」(package),是指一套已經寫好的工具。

軟體工程就像是蓋房子一樣,高樓不會從平地憑空冒出,而是要靠一磚一瓦堆疊建構而成,但這一磚一瓦不一定要全靠自己的徒手建構,而很多時候會大量仰賴別人做好的套件。

在軟體開發過程中我們會遇到很多問題,而程式設計師會開發對應的工具來解決這個問題。如果未來還會遇到類似的問題時,程式設計師會將程式碼打包成套件(package),並發佈到共享社群平台裡面(例如npm)。未來又遭遇到相同問題時,他就能從社群平台取得套件來處理,不必自己重頭撰寫。

Dont reinvent the wheel.jpg

(圖片來源:Linkedin)

軟體工程的專案成功,是因為我們不是自己一個人,而是站在許多開發者的技術結晶上向前邁進。在學術界常會引用牛頓的名言:「如果說我看得比別人更遠,那是因為我站在巨人的肩膀上。」(If I have been able to see further, it was only because I stood on the shoulders of giants.),而在軟體工程界則會說:「不要重新製造輪子!」(Don't reinvent the wheel)。因為軟體具有容易複製、穩定、發佈便利的特性,加上開放原始碼自由軟體精神和授權條款的盛行,所以在軟體工程界特別推崇使用別人所開發的套件,而不建議大家從頭開始打造專案。

npm套件管理工具 / npm: Node Package Manager

640px-Npm-logo.svg.png

(圖片來源:維基百科)

在Java、PHP的古早時代裡,程式設計師所開發的套件、函式庫、程式碼片段是在自己架設的網站上發佈,或是發佈在早期的程式碼保存平台上。這種發佈方式在管理上並不方便,不僅很難找尋,也常常遇到程式碼不完整、必需要先安裝其他套件才能正常運作的相依性問題。

2013年時,Isaac Z. Schlueter參考了PHP的PEAR和Perl的CPAN等作法,開發了npm套件管理工具。npm的全名為Node Package Manager,也就是node包管理工具。它是目前Node.js主要的軟體套件管理系統。

當我們提到npm的時候,它其實包含了三種不同的層面

  1. 註冊處(registry):登記與保存JavaScript套件的資料庫,這是所有npm運作的核心,但開發者不會跟它直接互動。
  2. 命令列介面 (Command Line Interface, cli):下載與發佈套件的命名列工具,這也是大部分開發者會接觸的套件。
  3. npm網站(website):套件平台的搜尋引擎與社交網站。開發者可以在網站上搜尋、發掘套件,也可以在上面建立自己的帳戶、組織,這樣就能發佈與管理公開或私人的套件。

看到這裡你應該可以發現到了。沒錯,如果我們想要發佈自己的套件,那除了要使用命令列工具npm之外,還要上npm網站註冊才行。

不過別急,在正式操作之前,我們還得對npm套件有更多的認識。

套件名稱與套件的發佈類型 / Package name and the access type

2019-0627-030227.png

要在npm註冊成為一個套件,我們必須為套件命名。套件名稱會存放在專案底下的套件資訊檔package.json裡面的欄位 "name" 中。

套件名稱有幾個基本規定:

  • 套面名稱最長只能在214字元以下
  • 套件名稱不能包含點「 . 」或是下底線「 _ 」
  • 套件名稱不能有大寫英文字
  • 套件名稱必須符合URL的安全字元。因為該名稱會成為網址、命令列參數和資料夾的一部分,所以任何可能造成上述使用狀況下會發生錯誤的字元都是不允許的。

因為有上述規定,常見的npm套件名稱大多是只有小寫英文字、數字、橫線「-」,以及私領域(scoped)或私人(private)套件才會使用的「@」和「/」。

2019-0627-025830.png

(圖片截自npm網站)

嗯?私領域套件?這個名稱好像在標題有講到過,這是什麼呢?

在npm發佈套件時,有三種發佈類型可以選擇

Win Winning Victory Victor Race Competition.png

(圖片來源:Pixabay)

npm的套件名稱是採用「先到先得」的方式註冊。如果某個套件名稱已經被人註冊,那我們就不能再用同樣的名稱註冊。也就是說如果我們取得別人的套件程式碼來修改,那就不能以同樣名稱發佈這個套件。

這時候除了將套件換一個名稱再以公領域套件發佈之外,比較好的方法應該是先註冊為私領域套件,確認套件運作正確之後,再來考慮用提交合併請求(pull request)將程式碼貢獻給套件的原始作者。

舉例來說,如果我們想要修改公領域套件「test-npm-module」並發佈在npm上,那套件名稱可能就必須調整為私領域套件「@pulipuli.chen/test-npm-module」。修改了名稱,也就成為了另一個套件了。


操作步驟 / Step by step

講了老半天,終於進入我們的正題了。

這一篇是為了教大家從別人開發好的原始套件開始,試著取得別人寫好的套件程式碼、修改程式碼、發佈成為npm私領域套件,最後再回饋給套件原始作者。整個流程有以下幾個步驟:

  1. 在npm網站與GitHub網站註冊帳號 (只有第一次需要做)
  2. 準備npm與git工具 (只有第一次需要做)
  3. 在本機端新增npm使用者 (只有第一次需要做)
  4. 取得原始套件的原始碼
  5. 修改套件資訊檔
  6. 初次發佈私領域套件
  7. 後續修改與發佈套件
  8. 回饋程式碼給原作者

步驟好像有點多,不過每一步都不複雜。以下操作我是在Windows 7和Ubuntu 16.04 LTS裡面各別進行,主要是用Ubuntu操作。讓我們一起來看看怎麼做吧。


Step 1. 在npm網站與GitHub網站註冊帳號 (只有第一次需要做) / Register an account in GitHub and npm website (first time only)

在正式開始之前,我們必須先有npm和GitHub這兩個網站的帳號。大部分npm套件的作者會將自己的套件程式碼放到GitHub上保存,然後再到npm發佈。因此我們也必須在這兩個網站都各自申請一個帳號。這個動作只有第一次需要做而已。

1-1. npm網站 / npm website

2019-0627-041423.png

如果要在npm發佈私領域套件,那我們必需要有npm網站的帳號。申請npm帳號是免費的,只需要填入全名(Full Name)、公開的Email位址(Public Email)使用者名稱(Username)、密碼(Password)即可。必須注意的是,Email位址跟使用者名稱都是公開資訊,而使用者名稱會成為你的私領域套件名稱的開頭,所以請謹慎命名喔。註冊步驟中系統會發送確認信件到你的Email,點選信件中的驗證連結即可完成註冊。

1-2. GitHub網站註冊 / Sing up in GitHub

2019-0627-041746.png

如果要取得別人套件的程式碼,並在之後回饋程式碼給原本套件的作者的話,在GitHub網站上使用git來合作是最好的選擇。GitHub的帳號註冊只要使用者名稱(Username)、Email位址(Email address)、密碼(Password)即可。

2019-0627-042416.png

後續GitHub會再問你訂閱模式、是否建立組織(organization)、是否發送電子報等問題,我們只要使用預設的免費模式,然後記得到Email點選認證信件裡面的連結完成註冊即可。


Step 2. 準備npm與git工具 (只有第一次需要做) / Prepare npm and git (first time only)

再來是我們要在本機端的電腦上準備能夠操作npm套件和GitHub網站的工具git。每臺電腦都只需要配置一次即可。

2-1. 安裝Node.js跟npm / Node.js and npm installation

590px-Node.js_logo.svg.png

(圖片來源:維基百科)

npm套件管理工具是Node.js的一部分,通常安裝好Node.js的時候,裡面就已經包含了npm。

install-node-msi-version-on-windows-step2.png

(圖片來源:RUNOOB.COM)

如果要在Windows上安裝Node.js,可以看「Node.js 安装配置」這篇的說明。安裝方式就跟一般的安裝精靈一樣簡單。

2019-06-27_185924.png 

如果要在Ubuntu上安裝最新版的Node.js,只用apt-get就只能安裝舊版。目前比較推薦的作法是用NodeSource的安裝腳本來安裝Node.js。請在Ubuntu的終端機(terminal)中輸入以下指令:

sudo apt-get install curl -y ; sudo curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash - ; sudo apt install nodejs -y ; node --version

注意黃底的10,這表示Node.js的版本。目前Node.js最新版本是12.4,但是長期支援的穩定版本是10.16,因此我會推薦大家先安裝10即可。

2019-0627-070115.png

看到最後出現了「v10.16.0」,表示Node.js已經順利安裝,而npm同時也會就定位。

2-2. git安裝 / git installation

Git.png

(圖片來源:iconscout)

要管理GitHub上面的檔案,除了在網頁上操作之外,通常大家會用git工具把GitHub上的資料下載(pull)到本機端,在修改檔案之後,後續也會用git做遞交(commit)與推送(push)等操作。

2014-08-18_154048[2].jpg

許多工具都有實作了git,選擇十分多樣。很多整合開發環境IDE裡面都有內建git。如果你已經有熟悉的開發工具,那我會建議你找找看你工具裡面有沒有git功能。我通常都是使用NetBeans來操作git,詳情請看我之前寫過的「Git合作開發從NetBeans開始!NetBeans複製git專案教學」。

TortoiseGit _ MSysGit GitHub.png

如果要使用獨立的git工具,我在Windows裡面最常用的是TortoiseGit。它的安裝與配置有點複雜,可以看我之前寫過的「GitHub入門 Part.2 工具安裝與環境配置」。

2019-0627-074942.png

如果是在Ubuntu的環境下,我會推薦直接使用指令列工具git,這個操作最簡單。我們可以直接使用apt-get來安裝git,指令如下:

sudo apt-get install git -y

這樣就完成git的安裝了,apt真的超方便。

2-3. 設定git使用者名稱和電子郵件 / Set git config

安裝好git之後,我們還需要設定git的使用者名稱和電子郵件帳號。這裡的設定通常會跟GitHub註冊的帳號相同。

根據你使用的git工具不同,設定使用者名稱和電子郵件帳號的方式會有點不太一樣。但最基本的就是使用git指令。在Ubuntu裡面,使用git指令設定使用者名稱和電子郵件的指令如下:

git config --global user.name "pulipulichen"
git config --global user.email "blog@pulipuli.info"

2019-0627-093021.png

到這邊為止,大部份Node.js開發者跟GitHub使用者的電腦應該早就有這樣的配置。即使你沒有發佈過npm套件,電腦也可能早已配置好Node.js跟git 工具。不過,接下來的操作,就跟套件的發佈比較相關了。讓我們繼續看下去吧。


Step 3. 在本機端新增npm使用者 (只有第一次需要做) / Add npm user in local computer (first time only)

2019-0627-080441.png

在npm準備好之後,我們接下來要在本機端電腦上登入npm註冊處。指令如下:

npm adduser

接著npm會問你 使用者名稱(Username)、密碼 (Password)、電子郵件地址 (Email)。三項資訊都是跟你在npm網站註冊帳號一樣的資料。

正確輸入之後,就會看到「Logged in as OOOOOO on https://registry.npmjs.org」了。

這個動作每臺電腦只需要做一次,之後就會一直維持相同的登錄帳號了。


Step 4. 取得原始套件的原始碼 / Get codes from a package

2019-0627-081322.png

(截圖來源:npm)

接下來我們要來取得別人發佈套件的原始碼。以下我以測試用的套件「test-npm-module」為例來說明。

我們可以在npm網站上用套件名稱搜尋到該套件,然後查看該套件的相關資訊。主要要注意的有兩個資訊:授權條款 (license) 和 保存庫 (repository)。

4-1. 授權條款 / License

2019-06-27_201755 - 複本(2).png

(截圖來源:npm)

第一個要注意的是授權條款 (license) 的資訊。雖然大部分套件都是開放原始碼,允許大家自由使用。但是各個開發者習慣採用的條款不盡相同,各條款所允許的範圍也不太一樣,要取用別人的程式碼之前,最好先確認一下授權條款的內容。

test-npm-module所採用的MIT授權條款是許多npm套件廣泛採用的其中一種,想要使用該程式碼的使用者只要在軟體副本中包含MIT著作權聲明,就可以使用、修改或發佈。因此我們接下來的修改和再發佈,都是符合授權條款的範圍中。

使用npm init建立套件資訊檔package.json時,它設採用的授權條款是ISC授權條款。它與知名的BSD授權條款很像,跟MIT授權條款相比,ISC和 BSD都允許使用者修改原作者名字後再發佈。

七种开源许可.jpg

(圖片來源:簡書)

許多開放原始碼的授權條款都看起來很像,只有幾句細微的差異。有興趣的人可以看看「七种开源许可证」這篇的比較。題外話,我比較喜歡 啤酒軟體條款 (Beerware)咖啡軟體條款 (Coffeeware) 。

4-2. 保存庫 / Repository

2019-0627-083358.png

(截圖來源:npm)

大部分npm套件的作者都選用GitHub作為原始碼的保存庫。感謝微軟爸爸的收購,現在GitHub還真是蓬勃發展。test-npm-module也將原始碼保存在github上,我們在它的npm套件頁面上點選保存庫(repository) github,就能開啟它的保存庫頁面。

2019-0627-084238.png

(截圖來源:github)

4-3. 分岔專案 / Fork

進入test-npm-module的保存庫頁面後,我們接下來要取得它的套件程式碼。最簡單的作法,就是直接將保存庫整個複製一份到你的GitHub帳號底下,這個操作在git裡面就叫做「分岔專案」(fork) 。

2019-0627-084610.png

點下Fork按鈕之後,GitHub就會開始複製檔案到你的帳戶底下。

分岔會保留原作者的大部分資訊,也會讓原作者知道有人分岔了他的程式碼。而這些在你帳號底下的程式碼,你就有權限能夠修改與變更它了。

4-4. 下載程式碼到本機端 / Clone repository to local computer

接下來我們要把GitHub上的程式碼放到本機端上,這樣不僅方便修改,而且也能夠在後續用npm發佈為另一個套件。

2019-0627-085504.png

(截圖來源:GitHub)

如果要取得GitHub保存庫的程式碼,我們要先取得保存庫的git網址。網址會放在右方的「Clone or download」(複製或下載)按鈕中,點開來後會顯示一個網址欄位,這就是該保存庫的git網址。

再來就要請你用本機端電腦上的git工具將整個保存庫複製(clone)到本機端。如果你是NetBeans的使用者,可以參考我之前寫的「Git合作開發從NetBeans開始!NetBeans複製git專案教學」這篇。

如果是在Ubuntu中使用git指令,那複製(clone)的指令如下:

git clone https://github.com/pulipulichen/test-npm-module.git

2019-0627-090104.png

這樣就會把GitHub的程式碼複製到你的本機端電腦上了。

2019-0627-090639.png

到這邊為止,我們成功了取得了別人套件的程式碼,接下來我們就要來修改裡面的檔案了。


Step 5. 修改套件資訊檔 / Revise package.json

2019-0627-090728.png

在修改套件程式碼之前,我們必須先修改別人套件的套件資訊檔 package.json。

大多時候package.json都是從空白資料夾透過「npm init」指令來建立。不過因為我們是從別人的套件開始改起,所以不需要用「npm init」建立package.json,而是直接修改別人的package.json。

2019-0627-091137.png

在套件資訊檔 package.json中,第一個要修改的就是套件名稱 name 的內容了。原本的套件名稱是「test-npm-module」,這是公領域套件的命名形式,我們要把它重新命名為私領域套件。因為我的npm帳號是「 pulipuli.chen」,所以作法就是在該套件名稱的開頭加上「@pulipuli.chen/」,最後就命名為「@pulipuli.chen/test-npm-module」。

此外,我們也可以加上contributors資訊,將你加入協作者中,格式像是:

"contributors": [
  {
    "author": "Pulipuli Chen",
    "email" : "blog@pulipuli.info", 
    "url" : "http://blog.pulipuli.info/"
  }
],

2019-0627-111239.png

修改完之後就成為這樣子了。詳細程式碼你也可以看我在GitHub的版本記錄


Step 6. 初次發佈私領域套件 / Publish scoped for the first time

將套件資訊檔修改之後,我們就能夠發佈私領域套件了。透過npm工具發佈套件的操作主要是以指令列進行。必須注意的是,第一次用指令發佈該套件的時候,需要加上「--access public」。

要發佈套件的時候,你的命名列所在的工作目錄(working directory)必須是與package.json相同的目錄。然後再來執行第一次發佈套件的指令:

npm publish --access public

2019-0627-094245.png

上圖就是Ubuntu的執行結果。

2019-0627-094502.png

(截圖來源:npm)

這樣子就成功在npm上發佈我們修改的套件了。接下來任何人都可以用「@pulipuli.chen/test-npm-module」這個套件名稱來安裝套件。套件安裝指令如下:

npm i @pulipuli.chen/test-npm-module

Step 7. 後續修改與發佈套件 / Revise package code and publish

上面我們只是修改了套件資訊檔 package.json,接下來我們可以任意修改裡面的檔案,再將修改的檔案發佈。

7-1. 第一個程式碼 / Find out main file

問題是,test-npm-module套件裡面到底要修改那個程式碼好呢?

2019-0627-111500.png

這時候請看package.json裡面的 "main" 所指向的檔案「./lib/test-npm-module.js」,這就是套件的起始檔案。

2019-0627-095306.png

讓我們打開 test-npm-module.js ,然後就用你的Node.js知識開始修改吧。

7-2. 修改版本號 / Increase version number

當你修改完成,需要再次發佈之前,你必須先更新你的版本號。

2019-0627-111534.png

版本號的位置一樣在套件資訊檔 package.json 的 version。npm套件的版本號由三個數字組成,中間用點「.」連接。第一個版本皆從「1.0.0」開始。根據npm版本語義的說明,這三個數字都有其意義。以下是不同版本號的說明:

程式碼狀態
Code status
階段
Stage
規則
Rule
範例
首次發佈新產品
New product
由1.0.0開始1.0.0
修正錯誤,且可以向後相容發佈補綴
Patch release
增加第三個數字1.0.1
新增功能,且可以向後相容小改版
Minor replease
增加第二個數字,然後將第三個數字歸零1.1.0
大幅改版,且不能向後相容大改版
Major release
增加第一個數字,然後將第二個和第三個數字歸零2.0.0

換句話說,版本號的三個數字,例如「1.2.3」,對應的改版程度是:

  • 1: 大改版的次數,大改版後就不能向後相容了。
  • 2: 大改版後新增功能(new feature)的次數,只要大改版數字相同就能相容。
  • 3. 大改版後修改錯誤(bug)的次數,只要大改版數字相同就能相容。

雖然版本號的數字並沒有強制的規定,你可以給版本號設定任意數字,不過還是建議大家能夠遵守這個規則來更新版本號。

好,話說回來,如果你要發佈更新後的套件,你需要新增版本號。舉例來說,原本的版本號是「1.0.0」,然後你修正了一個錯誤 (bug),那版本號就可以改為「1.0.1」。

7-3. 再次發佈 / Publish package

改好版本號之後,你就可以用npm再次發佈了。第二次之後的套件發佈指令可以簡單一點,指令如下:

npm publish

2019-0627-101505.png

這樣子就可以順利發佈囉。

2019-0627-101607.png

npm網站上的套件首頁也跟著改版了。

7-4. 安裝最新版套件 / Install lastest package

必須注意的是,剛發佈更新版套件的時,如果用npm指令安裝套件的話,它會先讓你安裝舊的套件版本。必需要等待一段時間之後,才會出現新的版本。

如果我們要立刻安裝最新版的套件的話,那必須要在npm安裝指令裡面加上@版本號。如果我們最新版的版本號是1.0.1,那麼安裝指令如下:

npm i @pulipuli.chen/test-npm-module@1.0.1

7-5. 小捷徑:不發佈就先測試套件 / Tip: Test package without publishing

2019-0627-103055.png

若照前面的步驟走,你必須先修改檔案、修改版本號、npm發佈、npm安裝、執行測試,這樣才知道套件能不能正常運作,但這樣實在是太累了。

如果你已經將套件安裝到本機端的Node.js專案中,那你可以選擇用另一種偷吃步的作法。

  1. 在Node.js專案的node_modules資料夾下找到該套件
  2. 直接修改本地套件(local package)的程式碼
  3. 在專案中測試套件是否正常運作
  4. 修改套件直到滿意為止
  5. 將有修改的程式碼放到套件主要的保存庫檔案
  6. 修改版本號,再發佈套件更新版

這樣偷吃步的作法可以省下不少修改的功夫。不過你可能要注意專案本地套件你實際上發佈的套件中,套件資訊檔pacakge.json以及一些根目錄的檔案不全然相同。

另一種作法是直接在Node.js專案中安裝本機端的套件為止,安裝指令如下:

npm install /absolute/local/path/to/your/other/package

紅色文字就是你的套件檔案路徑了。詳細作法請看「Node.js — How to test your new NPM module without publishing it every 5 minutes」這篇的說明。


Step 8. 回饋程式碼給原作者 / Feedback to the author of package

當你將別人的套件改得差不多了,那你可以考慮將新增的程式碼回饋給原本的作者。在GitHub的保存庫上,我們主要是透過提交合併請求(pull request, PR)來交換程式碼。不過在提交PR之前,我們要先把位於本地端電腦上的套件檔案,推送到GitHub的保存庫中。

8-1. 還原套件名稱為原始名稱 / Restore the original name of package

2019-0628-122633.png

因為我們要把程式碼回饋給原作者了,所以要先把套件名稱從私領域套件還原成公領域套件。我們一樣開啟package.json,將 "name" 欄位的套件名稱從「@pulipuli.chen/test-npm-module」還原成「test-npm-module」即可。

8-2. 上傳保存庫:新增、遞交與推送 / Upload repository: Add, commit and push

我們要透過git指令來將本地端的檔案推送到GitHub,雖然背後有些複雜的git概念,但簡單來說指令只有以下三行:

git add .
git commit -m "Describe your commit"
git push

其中紅字的部分請填入你為這次改版的簡單敘述。在執行「git push」之後,系統會請你輸入GitHub的使用者帳號和密碼,輸入正確就能順利將本機端的檔案上傳到GitHub中。關於這些指令的意義,請參考「Git 簡易使用教學」這篇的教學。

2019-06-27_225956.png

2019-0627-114345.png

如果沒有什麼特別的錯誤訊息,那就是已經推送完成。

2019-0627-110228.png

你的GitHub網站上的程式碼已經會是最新版的內容,可以注意到中間會有剛剛遞交輸入的相關資訊。

8-3. 提交合併請求 / Pull request

2019-0627-111712.png

在GitHub上要發起提交合併請求,請按分支(Branch)按鈕旁邊的「New pull request」(新的提交合併請求)。

2019-0627-111832.png

接著請設定你要提交的分支,以及原作者保存庫的分支,下面會顯示兩者版本之間有差異的程式碼,通常這時候你會看到你新增或修改的功能,以及套件資訊檔 package.json 裡面添增的資訊。確認無誤之後,再按下綠色的「Create pull request」(建立提交合併請求)按鈕,進入下一步。

2019-0627-112453.png

再來輸入提交合併請求訊息的標題與內文,然後按下「Create pull request」,這樣提交合併請求就完成了。

接著原作者會收到提交合併請求的通知,他可以查看訊息、檢視PR跟現在版本之間的差異,最後按下接收合併按鈕。詳細細節請看「與其它開發者的互動 - 使用 Pull Request(PR)」的教學吧。

8-4. 修改套件名稱為私領域套件 / Revise the name of package to scoped package

2019-0628-123105.png

如果我們還要繼續修改套件並發佈成私領域套件,那要記得把套件名稱改回為私領域套件「@pulipuli.chen/test-npm-module」,然後就可以回到Step 7繼續修改套件囉。


結語 / Conclusion

Using Gerrit with GitHub - Luca Milanesio.png

(圖片來源:stackoverflow)

這篇的內容橫跨了npm與git兩種技術。這兩種技術的教學已經很容易在網路上找到,但是大多都只是談單一指令、講述git版本控制背後的原理和複雜的操作,或是從空專案開始建立npm套件。

就如今日的軟體工程已經不會有人從平地開始徒手打造房屋一樣,很多時候我們也不會想要從頭開始建立套件,而是想要把套件改得更好。感謝Node.js有一個好用的套件管理工具npm,也感謝GitHub平台保存了各種開放原始碼,我們這篇藉由分岔(fork)來取得別人寫好的套件程式碼,然後利用npm發佈成私領域套件,完成之後又能以提交合併請求(pull request)回饋給原作者,讓開放原始碼的開發者彼此合作、一起製造更精良的輪子。

participation-opensource-cc.png

(圖片來源:Opensource.com)

開放原始碼社群鼓勵大家共享程式碼。以前我都只是將程式碼上傳到特定空間,然後在Blog放上連結,但其實這樣並不是參與開放原始碼社群的積極態度。舉例來說,我之前用JavaScript寫成的滯後序列探勘只是一個獨立網頁,如果將它包裝成套件,那就能讓更多人直接結合到網頁系統使用。可惜那時候對Node.js還不夠熟悉,程式碼寫的實在是爛到很難重構。

現在深入瞭解Node.js和npm套件的便利之後,我想未來我會更積極地將JavaScript程式碼包裝成套件,回饋給開放原始碼社群吧。希望Node.js社群能繼續蓬勃發展,不要輸給Python社群啊(?) !

題外話 / Off topic

2019-06-27_150026.png

(圖片截自npm網站)

接下來我就來聊點題外話。因為這是題外話,所以我會使用大量術語和專有名詞,只是想要講講我最近遇到的事情而已。如果你看不懂也沒關係,反正只是個題外話。

我會寫這一篇的原因,是因為我需要在Electron環境下使用搜尋功能。我本來以為Electron只是一個簡易版的Chrome瀏覽器,但實際上用起來才發現,他真的太簡陋了!預設環境下,我們不僅不能用搜尋,連右鍵選單都沒有內建。這可以當作是Electron為了應用程式提供的彈性,不去硬性規定應用程式應該要有的樣貌。可是這對像我這樣只是想要輕鬆建立個應用程式的人來說,這也太麻煩了。

還好,很多人為了解決這些問題而幫Electron開發了相關套件。右鍵選單的套件可用electron-context-menu。它的設定有點抽象,需要摸索一下用法,但大致上還算是正常運作。

2019-0628-125001.png

搜尋功能也有對應的套件,那就是electron-in-page-search。但不知道是我的Electron版本的問題,還是Windows作業系統環境的問題,還是什麼其他原因,總之electron-in-page-search實在是一堆Bug。首先是找到符合搜尋條件的計算次數永遠會多一個,然後不能使用「<」跟「>」跳到前一個或後一個搜尋結果,甚至是我在輸入中文的時候會把輸入框關閉。

本來以為可以用一些偷吃步作法,隱藏那些有Bug的功能。但是跟中文輸入法過不去這點實在是讓人難以忍受,所以我還是想想辦法來把electron-in-page-search複製一份,並發佈成私領域套件@pulipuli.chen/electron-in-page-search。我大致上修正了中文輸入法的錯誤,但還是很多Electron相關的搜尋功能看不太懂。

另一個問題是,原作者是用TypeScript編譯成JavaScript後才發佈成npm套件,但他在GitHub上的原始碼並沒有遞交編譯後的JavaScript,只有原始的TypeScript檔案。這就得讓人額外再準備TypeScript編譯環境、瞭解TypeScript的語法,才能修改他的套件內容。不得不說這真的有點折騰。

喔對了,這篇舉的例子test-npm-module,其實他的原始碼可是用CoffeeScript寫成的呢。不論是TypeScript還是CoffeeScript,他們都是改善原本JavaScript的另一種程式語言。哎呀,軟體工程要學的東西實在是好多喔 orz

2019-0628-011814.png

好啦,這篇依然是繼續為Blogger Editor抓錯。雖然繼上一篇之後又修正了幾個小問題,但這篇寫一寫又遇到了其他問題。

可以在沒有發現bug的情況下寫完一篇的那個日子,什麼時候才會來到呢?


這篇這樣寫著寫著也快要6000字了,還有快70張圖片,花了一整天的時間再寫這篇。好啦,那這次對npm私領域套件的取得、修改、發佈與回饋的教學就寫到這裡了。你是Node.js的開發者嗎?你對npm套件有什麼想法呢?你對於把自己寫好的程式碼回饋給開放原始碼社群有什麼看法呢?

歡迎在下面的留言處跟我們分享你的想法。大家的意見是我繼續分享的動力喔!如果你覺得我這篇閒聊算是有趣的話,請幫我在AddThis分享工具按讚、將這篇分享到Facebook等社群媒體吧!感謝你的耐心閱讀,我是布丁,讓我們下一篇見。

總共6 則留言 ( 我要發問 , 隱藏留言 顯示留言 )

  1. 非常好的文章,看了有收获,。

    回覆刪除
  2. 哈囉您好,很感謝您的清楚記錄!
    前幾天剛好需要微調 npm 上的套件後再重新發布,作為測試。
    而自己摸索好久後才查到您的文章,發現很多疑惑跟問題都解決了!

    回覆刪除