package.json vs go.mod: വേർഷൻ ഫീൽഡ് എവിടെപ്പോയി?

𝗣𝗮𝗰𝗸𝗮𝗴𝗲.𝗷𝘀𝗼𝗻 vs 𝗚𝗼.𝗺𝗼𝗱: വേർഷൻ ഫീൽഡ് എവിടെപ്പോയി?

നിങ്ങൾ JavaScript-ൽ നിന്ന് Go-ലേക്ക് മാറുന്നുണ്ടെങ്കിൽ, ഒരു കാര്യം നിങ്ങളെ അത്ഭുതപ്പെടുത്തും.

ഒരു package.json ഫയലിൽ, വേർഷൻ ഏറ്റവും മുകളിൽ തന്നെ കാണാം. നിങ്ങൾക്ക് അത് വായിക്കാം. ഒരു pull request-ലൂടെ നിങ്ങൾക്ക് അത് മാറ്റാം. നിങ്ങൾക്ക് അത് തിരയാം. നിങ്ങളുടെ കോഡിനുള്ളിൽ തന്നെ നിലനിൽക്കുന്ന ഒരു വസ്തുതയാണിത്.

ഇനി ഒരു go.mod ഫയൽ തുറന്നു നോക്കൂ. അവിടെ വേർഷൻ കാണാനില്ല.

ഇതൊരു തെറ്റല്ല. ഇതൊരു തിരഞ്ഞെടുപ്പാണ്.

നിങ്ങളുടെ സ്വന്തം മോഡ്യൂളിനായി Go ഒരു version field ഉപയോഗിക്കുന്നില്ല. പകരം, Go git tags ആണ് ഉപയോഗിക്കുന്നത്.

Go-യിൽ ഒരു വേർഷൻ സെറ്റ് ചെയ്യാൻ നിങ്ങൾ ഇത് ചെയ്യണം:

• git tag v1.2.3
• git push origin v1.2.3

git tag ആണ് ഏക ആധികാരിക ഉറവിടം (single source of truth). ആരെങ്കിലും go get റൺ ചെയ്യുമ്പോൾ, ശരിയായ commit കണ്ടെത്താനായി Go നിങ്ങളുടെ റിപ്പോസിറ്ററി ടാഗുകൾ പരിശോധിക്കുന്നു.

ഈ ഡിസൈനിന് വലിയൊരു ഗുണമുണ്ട്. ഒരു വേർഷന് ഒരിക്കലും തെറ്റായ കോഡിലേക്ക് വിരൽ ചൂണ്ടാൻ കഴിയില്ല. npm-ൽ, പബ്ലിഷ് ചെയ്ത കോഡും ടാഗ് ചെയ്ത സോഴ്സും തമ്മിൽ വ്യത്യാസം വരാൻ സാധ്യതയുണ്ട്. എന്നാൽ Go-യിൽ അവ രണ്ടും ഒന്നാണ്, കാരണം വേർഷൻ എന്നത് ഒരു commit-ലേക്കുള്ള പോയിന്റർ ആണ്.

എന്നിരുന്നാലും, ഇത് നിങ്ങളുടെ വർക്ക്ഫ്ലോയെ പല രീതിയിൽ മാറ്റുന്നു:

• വേർഷൻ കണ്ടെത്താൻ ഒരു കമാൻഡ് ആവശ്യമാണ്. ഒരു ഫയൽ നോക്കുന്നതിന് പകരം നിങ്ങൾ git describe --tags റൺ ചെയ്യണം.
• വേർഷൻ മാറ്റങ്ങൾ (version bumps) കോഡ് റിവ്യൂകളിൽ കാണില്ല. ഒരു ടാഗ് പുഷ് ചെയ്യുന്നത് കോഡിൽ വരുത്തുന്ന മാറ്റമല്ല, അതിനാൽ അത് ഒരു pull request-ൽ പ്രത്യക്ഷപ്പെടില്ല.
• ലോക്കൽ ബിൽഡുകൾ pseudo-versions ആണ് ഉപയോഗിക്കുന്നത്. നിങ്ങൾ ഒരു commit ടാഗ് ചെയ്യുന്നത് വരെ, v1.2.3 പോലുള്ള ഒരു വൃത്തിയുള്ള വേർഷന് പകരം നമ്പറുകളുടെയും ഹാഷുകളുടെയും (hashes) ഒരു നീണ്ട സ്ട്രിംഗ് ആണ് കാണുക.
• മേജർ വേർഷനുകൾ നിങ്ങളുടെ import path മാറ്റുന്നു. npm-ൽ, നിങ്ങൾ വേർഷൻ നമ്പർ മാറ്റുന്നുണ്ടെങ്കിലും പാക്കേജ് പേര് മാറ്റുന്നില്ല. എന്നാൽ Go-യിൽ, v2-നും അതിനു മുകളിലും /v2 പോലുള്ള ഒരു പാത്ത് മാറ്റം ആവശ്യമാണ്. ഇത് ഒരേ ലൈബ്രറിയുടെ v1, v2 എന്നിവ ഒരേസമയം തടസ്സങ്ങളില്ലാതെ ഉപയോഗിക്കാൻ ഒരു പ്രോഗ്രാമിനെ അനുവദിക്കുന്നു.

മിക്കവാറും മറ്റ് ഇക്കോസിസ്റ്റങ്ങൾ വേർഷൻ ഒരു ഫയലിൽ സൂക്ഷിക്കുന്നു:

• Node: package.json
• Rust: Cargo.toml
• Python: pyproject.toml
• Java: pom.xml
• .NET: .csproj

Go വ്യത്യസ്തമാണ്. അത് git tags-നെ മാത്രം ആശ്രയിക്കുന്നു.

നിങ്ങളുടെ Go binary-യിൽ ഒരു വൃത്തിയുള്ള വേർഷൻ കാണിക്കണമെന്നുണ്ടെങ്കിൽ, ബിൽഡ് പ്രക്രിയയിൽ ldflags ഉപയോഗിച്ച് നിങ്ങൾക്ക് അത് ഉൾപ്പെടുത്താം. ടാഗ്, റിലീസ് പ്രക്രിയകൾ ഓട്ടോമേറ്റ് ചെയ്യാൻ പല ഡെവലപ്പർമാരും goreleaser പോലുള്ള ടൂളുകളും ഉപയോഗിക്കുന്നു.

ഈ രണ്ട് മോഡലുകളും വ്യത്യസ്ത മുൻഗണനകളെ പ്രതിനിധീകരിക്കുന്നു:

• ഫയൽ അടിസ്ഥാനമാക്കിയുള്ള വേർഷനുകൾ വായിക്കാനും റിവ്യൂ ചെയ്യാനും എളുപ്പമാണ്. എന്നാൽ ആ ഫയൽ യഥാർത്ഥ കോഡിൽ നിന്ന് വ്യത്യാസപ്പെടാൻ സാധ്യതയുണ്ട്.
• ടാഗ് അടിസ്ഥാനമാക്കിയുള്ള വേർഷനുകൾ വ്യാജമായി ഉണ്ടാക്കാൻ കഴിയില്ല. എന്നാൽ അവ കാണാനും കൈകാര്യം ചെയ്യാനും പ്രയാസമാണ്.

മാണിഫെസ്റ്റ് (manifest) എപ്പോഴും കോഡുമായി പൊരുത്തപ്പെടുന്നു എന്ന് ഉറപ്പാക്കാൻ Go ടാഗ് മോഡൽ തിരഞ്ഞെടുത്തു.

Go കോഡ് വിതരണം ചെയ്യുന്നവർക്കായി: നിങ്ങളുടെ ദൈനംദിന ജോലിയിൽ 'tag-only' മോഡൽ എങ്ങനെ അനുഭവപ്പെടുന്നു? നിങ്ങൾ അത് മാറ്റാൻ ആഗ്രഹിക്കുന്നുണ്ടോ?

Source: https://dev.to/dalirnet/packagejson-vs-gomod-where-did-the-version-field-go-3301