e
sv

Moon ile repo yönetimini iyileştirin

avatar

Yazılım Method

  • e 0

    Mutlu

  • e 0

    Eğlenmiş

  • e 0

    Şaşırmış

  • e 0

    Kızgın

  • e 0

    Üzgün

Node.js ve Git bu eğitim için önkoşullardır.

Yazılım geliştirme sadece kaynak kodu yazmayı değil, aynı zamanda üzerinde çalıştığımız kaynak kodun verimli bir şekilde yönetilebilmesini ve versiyonlanabilmesini de içerir.

Uygun sürüm oluşturma yoluyla kaynak kodumuzun geçmişini çizebiliriz; kolayca ileri geri gidebilir ve belirli sorunların ortaya çıkmasına neden olan değişikliklere işaret edebilir; Onları tamir etmek; başkalarıyla işbirliği yapmak; dallanıp bir projenin gidebileceği başka bir paralel yönü takip etmek; ve benzeri.

Versiyon kontrol sistemleri ile ortaya çıkan tüm bu olanaklarla birlikte, özellikle projeler büyüdüğünde, çözümlerin doğru yönetilmediğinde yeni sorunlara yol açması çok kolay olduğundan, havuzları verimli bir şekilde yönetmenin önemli hale geldiği bir noktaya gelinmektedir.

İçine daha fazla özellik eklendikçe büyüyen basit bir JavaScript projesi hayal edin. Bağımlılıkları zamanla artar. Benzer şekilde, geliştirme, önizleme, test etme, biçimlendirme, linting, oluşturma ve muhtemelen sürekli entegrasyon dahil edilen bağımsız bağımlılıklarıyla birlikte komut dosyalarının sayısı artar.

Kolayca yönetilemez hale gelebilecek çok sayıda bu çoklu repoları yönetiyor olabilirsiniz ve bu nedenle monorepo yoluna gitmeye karar verebilirsiniz. Böyle bir depoyu düzgün bir şekilde yönetmezseniz, bu en iyi çözüm olmayabilir.

Tüm bu zorluklar, normal paket yöneticilerinin sunduklarının ötesinde kaynak kod havuzlarını düzgün bir şekilde yönetmemize yardımcı olabilecek araçlara duyulan ihtiyacı artırıyor.

moon, kaynak kod havuzlarını yeterli otomasyonla verimli bir şekilde yönetmeye yardımcı olan böyle bir araçtır. Bu konuda daha fazla bilgi edelim:

ay nedir?

moon, JavaScript tabanlı projeler için bir havuz yönetimi, organizasyonu, orkestrasyon ve bildirim aracıdır – veya daha basit bir ifadeyle, Rust ile yazılmış JavaScript ekosistemi için bir yapı sistemidir.

Moon içindeki kavramların çoğu, Bazel ve diğer popüler yapı sistemlerinden büyük ölçüde esinlenmiştir, ancak JavaScript ekosistemi için uyarlanmıştır.

Rust'ta yazıldığından, moon yalnızca şu anda açıkça derlenen hedefleri destekler:

  • Linux 64-bit GNU (x86_64-bilinmeyen-linux-gnu)
  • Linux 64-bit musl (x86_64-unknown-linux-musl)
  • macOS 64-bit Intel (x86_64-apple-darwin)
  • macOS 64-bit Silikon (aarch64-apple-darwin)
  • Windows 64-bit (x86_64-pc-windows-msvc)

ayın temel özellikleri

Diğer yapı sistemleri gibi, moon, depoları normal paket yöneticileri üzerinde verimli hale getiren bir dizi özellik sunar. İşte bu özelliklerin bir özeti:

  • Görevler : Aydaki görevler, bir proje bağlamında çalıştırılan komutlardır. Kısaca görevler, alt süreçler olarak çalıştırılan npm ikili dosyaları veya sistem komutlarıdır.
  • Bağımlılık grafikleri : moon, görevler arasında topolojik sırada çalışacak şekilde bir bağımlılık grafiği oluşturur. Görevleri kurarken, birazdan göreceğimiz gibi, görevleri diğer görevlere bağımlılıklar olarak tanımlayabiliriz. moon dg komutu ile çalışma alanı içerisindeki tüm aksiyonların, hedeflerin ve görevlerin bağımlılık grafiklerini oluşturabiliyor ve Graphviz DOT formatında çıktısını alabiliyoruz.

    Bağımlılık Grafiği
    moon dg komutundan bağımlılık grafiği
  • Paralel yürütme : ay, uygun olduğunda görevleri paralel olarak çalıştırır. Örneğin, adlandırılmış görevi, uygulanabilir oldukları tüm paketlerde paralel olarak çalıştırmak için ayın run :<task-name> komutunu kullanabiliriz.
  • Önbelleğe Alma : Görevler, bağımlılık grafiğindeki her düğümde aşamalı olarak önbelleğe alınabilir. Böylece, ne kadar çok görev çalıştırılırsa, o kadar hızlı olurlar. Bu, performansı artırır ve hızlı çalışma sağlar
  • Görevlerin ayrıntılı yapılandırması: Aydaki görevler , ayrıntılı yapılandırılabilir seçenekleri destekler. Daha sonra görevleri oluştururken de göreceğimiz gibi, görevler çalıştırıldığında ne zaman, nasıl ve ne olması gerektiğine karar veren bir dizi seçeneğimiz var.
  • moon, çoğu yapı sistemi gibi, "etkilenen kod" üzerinde çalışır. moon, her çalıştırmada kaynak karmaları oluşturarak artımlı derlemeleri çalıştırabilir, bu nedenle devam eden çalıştırmalarda, tanıdık karmalar gözlemlenir ve çalıştırmalar iptal edilir; yalnızca yeni karma çalıştırmalara yol açan değiştirilmiş kod. Bu genel olarak gereksiz yeniden yapılandırmalardan kaçınarak yüksek performans sağlar
  • CI (sürekli entegrasyon) : moon, moon ci komutuyla CI'yi birinci sınıf bir özellik olarak sunar. Bu komut, araç zincirini ve proje bağımlılıklarını kurarak işlerin verimli bir şekilde yürütülmesini sağlar; etkilenen hedeflerin belirlenmesi ve yürütülmesi; iş parçacığı havuzunu kullanarak grafik içinde eylemlerin yürütülmesi; ve son olarak, başarılı, başarısız veya geçersiz eylemlerle ilgili istatistikleri görüntüleme

Moon ile bir repo yönetme

Yukarıda tartışılan özellikleri tam olarak anlamak için moon'u iş başında görmemiz gerekiyor – yani bir depoyu yönetiyoruz. Bu özellikleri, bir ön uç istemcisi ve bir arka uç sunucusu içeren bir monorepo deposunu yöneterek göstereceğim. Bir monorepo ile gitmeyi seçtim, çünkü bunun sayesinde ayın maksimum potansiyelinden yararlanabilir ve çoklu repo kurulumunda yapabileceğimizden daha fazla özelliği kapsayabiliriz.

Depo yönetimi için ay kurulumu

Yeni bir projeyi yönetmek veya mevcut repoları bir monorepo kurulumuna geçirmek için moon up kurabiliriz. İlki kolay bir kurulum olduğundan, ikincisine odaklanacağız.

Aşağıdaki talimatlar, şu anda aşağıdaki çoklu repo kurulumunda yönetilen bir e-ticaret mağazasını nasıl taşıyabileceğimizi gösterecek:

Gördüğünüz gibi, bu depoların her ikisi de nihai proje değil. İstemci çıplak bir Vue 3 iskelesidir ve sunucu bir ekspres prizma REST API örneğidir. Bunu bilerek yaptım, böylece Git geçmişlerimizi sağlam tutarken projelerimizi bir monorepo kurulumuna nasıl taşıyabileceğimizi görelim. Sonrasında monorepoda her iki projede de çalışmaya nasıl devam edebileceğimizi göreceğiz.

Monorepo'muzu yönetmek için moon'u kullanmak için önce yeni bir monorepo deposu kurmamız gerekiyor.

 git init estore && cd estore

Repo dizinimizin içine aşağıdaki betiği çalıştırarak bir package.json dosyası ekleyin.

 # npm
npm başlangıç

#pnpm
pnpm başlangıç

Ardından, bir .gitignore dosyası ekleyin, mevcut dosyaları hazırlayın ve ilk işlemi yapın.

 git commit -m "İlk taahhüt"

Mevcut depoları geçmişleriyle birlikte taşıma

Repomuzun içinde, estore-client ve estore-server adlı iki projemizi bir apps/ dizini altına yerleştireceğiz.

Bu yüzden başlangıçta o klasörü monorepomuzda mkdir apps ile oluşturacağız. Ve monorepo dizinimize estore adını verdiğimiz için, projelerimizden estore önekini kaldıracağız ve client ve server ile kalacağız.

Şu anda iki projenin, sunucu ve istemcinin geçmişlerini korumak için, onları estore eklerken her iki havuzu için de aşağıdakileri yapacağız.

Önce istemciden başlayarak, taşınmakta olan uygulama depomuzun içine bir git remote ayarlayın.

 git uzaktan istemci ekle git@github.com:xinnks/estore-client

Not, devam etmeden önce herhangi bir sorundan kaçınmak için bu uzak havuzlardaki açık PR'leri birleştirdiğinizden emin olun.

Daha sonra şubeye bakmadan kumandadan alarak kodu alacağız.

 git müşteri getir

Ardından, uzaktan kumandanın ana dal Git geçmişini --prefix bayrağının yardımıyla apps/client dizinine kopyalamak için aşağıdaki betiği çalıştıracağız.

 git okuma ağacı --prefix=apps/client -u client/master

estore git status ile önizleyerek aşağıdaki günlüğü elde ederiz.

 Şube yöneticisinde
Taahhüt edilecek değişiklikler:
  (stage'i kaldırmak için "git restore --staged <file>..." kullanın)
        yeni dosya: apps/client/.eslintrc.js
        yeni dosya: apps/client/.gitignore
        yeni dosya: apps/client/.prettierignore
        yeni dosya: apps/client/.prettietrc.json
        yeni dosya: apps/client/.vscode/extensions.json
        yeni dosya: uygulamalar/istemci/LICENSE
        yeni dosya: apps/client/README.md
        yeni dosya: apps/client/index.html
        yeni dosya: apps/client/package.json
        yeni dosya: apps/client/pnpm-lock.yaml
        yeni dosya: apps/client/project.yml
        yeni dosya: apps/client/public/vite.svg
        yeni dosya: apps/client/src/App.vue
        yeni dosya: apps/client/src/assets/vue.svg
        yeni dosya: apps/client/src/components/HelloWorld.vue
        yeni dosya: apps/client/src/main.js
        yeni dosya: apps/client/src/style.css
        yeni dosya: apps/client/vite.config.js

Değişiklikleri aşamalandırarak bu adımı sonlandıracağız.

 # Aşama değişiklikleri
git commit -m "feat: İstemci uygulaması ekle" uygulamaları/istemcisi

Depomuzun geçmişini önizleyerek, daha önce client yapılan tüm taahhütlerin estore geçmişinin bir parçası olduğunu göreceğiz.

Artan Geçmiş

Bu özel örnekte, estore-client'ın geçmişinin monorepo'nun First taahhüdünden önce geldiğini görebiliriz çünkü ikincisi birincisinden sonra yaratılmış ve işlenmiştir.

Uzak sunucusunu adlandırarak estore-server deposu için bu adımları tekrarlayın.

Tamamlandığında, böyle bir şeyle sonuçlanacağız.

Tamamlanmış Geçmiş Uzak Depoları

Artık estore içinde başlatmaya hazırız.

Ay CLI'yi yükleme

moon'un CLI'si, @moonrepo/cli npm paketi içindeki tek bir ikili dosya içinde gönderilir. Komutlarını yalnızca package.json komut dosyalarına güvenmek yerine herhangi bir dizinden çalıştırmayı basitleştirmek için CLI'nin global olarak yüklenmesi önerilir.

Kullanmakta olduğunuz paket yöneticisinden bağımsız olarak, genel kurulum her zaman npm kullanılarak yapılmalıdır.

 npm install -g @moonrepo/cli

Ardından, CLI'yi deponuza aşağıdaki gibi ekleyin.

 # iplik
iplik ekleme --dev @moonrepo/cli

# npm
npm kurulumu --save-dev @moonrepo/cli

# pnpm
pnpm ekle -D @moonrepo/cli -w

Global ikiliyi kullanırken, moon, package.json içindeki bir deponun dependencies bölümünde tanımlananla aynı sürümün kullanılmasını sağlar.

CI (sürekli entegrasyon) gibi senaryolar için aşağıdaki package.json betiği üzerinden moon çalıştırılabilir.

 {
  "Kodlar": {
    // ...
    "ay ay",
    // İplik 2+
    "moon": "$(iplik kutusu ay)"
  }
}

Ancak böyle bir kurulum, Node.js'yi başlatmanın genel maliyetini ve Rust ikili dosyasını yürütmek için paket yöneticisini beraberinde getirir. Böyle bir durumda, global ikili kurulum tavsiye edilir.

Ayrıca bu kurulum, komut dosyası depo kökünden çalıştırılmadığı sürece paket çalışma alanlarıyla çalışmaz.

Moon CLI'yi kurduktan sonra, artık bu script ile repomuzda moon başlatabiliriz.

 ay başlangıcı

Ay'ı başlattığımız dizini ve
Kullandığımız paket yöneticisi.

Çalışma Alanları

Çalışma alanı, projeleri içeren, bir araç zincirini yöneten, görevleri çalıştıran ve bir VCS deposuyla birleştirilmiş bir dizindir. moon, çalışma alanları için birinci sınıf desteğe sahiptir. Bir gereklilik olmasa da, onları kurmak ayın felsefesine uygundur.

Bir çalışma alanının kökü, bir .moon dizini ve bir package.json dosyası ile belirtilir.

Çalışma alanlarını projemizde kullanmak için kullandığımız paket yöneticisine bağlı olarak gerekli konfigürasyona göre onları etkinleştirmemiz gerekiyor. İşte çeşitli konfigürasyonlar.

Yarn/npm için (package.json)

 {
  "çalışma alanları": ["uygulamalar/"]
}

pnpm için (pnpm-workspace.yaml)

 paketler:
  - 'uygulamalar/'

Ay'da çalışma alanlarını yapılandırma

moon init komutunu çalıştırdıktan sonra oluşturduğumuz yeni oluşturulan .moon dizini içinde bulunan workspaces.yml dosyasını düzenleyerek çalışma alanımızı yapılandırabiliriz.

Bu dosyada kurabileceğimiz ayarların listesi aşağıdadır.

Projemizin düzenine göre yapılandıracağız.

Node.js

.moon/workspace.yml dosyasının node bölümü altında ay komutlarını çalıştırırken kullanılacak Node.js versiyonunu tanımlayabiliriz. Bu, aynı çalışma alanı havuzunda farklı projeler üzerinde çalışan olası farklı geliştirme ekipleri arasında tutarlılığı sağladığı için önemlidir.

 düğüm:
  sürüm: '16.16.0'

Not, node.version ayarı açık bir anlamsal sürüm gerektirir. Sürüm aralıklarını desteklemez. moon ayrıca bir Active LTS Node.js sürümünün kullanılmasını önerir .

Paketleme yöneticisi

moon, varsayılan paket yöneticisi olarak npm'yi kullanır. Bunu değiştirmek ve paket yöneticisini tercihlerimizden birine ayarlamak için node.packageManager workspace.yml içinde güncellememiz gerekiyor. Bu değeri npm , yarn veya pnpm olarak ayarlayabiliriz.

 düğüm:
  sürüm: '16.16.0'
  paket Yöneticisi: 'pnpm'

Normalde moon, bir paket yöneticisinin en son sürümünü yükler, ancak hiçbir zaman tutarlı bir şekilde güncellenmez. Bu nedenle, tıpkı Node.js sürümünde olduğu gibi, bunun için açık bir anlamsal sürüm tanımlamanız önerilir.

Bu, alet zincirimizde tutarlılık sağlar. Paket yöneticiniz olarak npm seçtiğinizde bile yapılmalıdır.

 düğüm:
    sürüm: '16.16.0'
    paket Yöneticisi: 'pnpm'
    pnpm:
      sürüm: '7.8.0'

Düğüm ve paket yöneticisi sürümlerini ayarladıktan sonra, her ikisinin de kurulu olduğunu doğrulamak için aşağıdaki komut dosyasını çalıştırın.

 ay --log hata ayıklama kurulumu

Bu komut, araç zincirimiz için gerekli araçları yapılandırıldığı gibi indirecek ve kuracaktır.

Sürüm kontrol sistemi

moon, farklılık, karma ve revizyon karşılaştırması için bir sürüm kontrol sisteminin bulunmasını gerektirir. Varsayılan olarak Git kullanılır ve bu nedenle bu ayar atlanabilir.

Ancak tutarlılık için bunu da ayarlayın. Bunu vcs ayarı üzerinden yapabiliriz.

 vcs:
    yönetici: 'git'
    defaultBranch: 'usta'

NB, SVN şu anda deneyseldir, bu nedenle düzgün çalışmayabilir.

Aydaki projeler

Bir proje, bir uygulamadan, kitaplıktan veya araçtan herhangi bir şey olabilir. Her birinin kendi yapı katmanı, bireysel görevleri ve özel yapılandırması vardır.

Yapılandırılan çalışma alanımızla, altında mümkün olduğunca çok proje barındırabiliriz.

Bu noktada, apps dizini içinde client ve server projeleri var, ancak bunları workspaces dosyasında bulunan projects ayarında eşleştirene kadar moon'dan erişilemez.

projects ayarı, çalışma alanımızda bulunan tüm projelerin (veya dosya sistemi kürelerinin) bir haritasıdır. Projelerimizi bir key: value biçiminde listeleriz, burada anahtarın bir proje için benzersiz bir kimlik olduğu ve değerin, çalışma alanı köküne göre projeye giden dosya yolu olduğu.

Şu anda workspaces.yml örnek bir proje example: 'apps/example . Bunu kaldırın ve aşağıdaki gibi iki projemizi yansıtacak şekilde client ve server projelerini ilgili dosya yollarıyla ekleyin.

 projeler:
    sunucu: 'uygulamalar/sunucu'
    istemci: 'uygulamalar/istemci'

Çalıştırılan moon project <project-key> , projenin konfigürasyonunu hem genel hem de yerel ay konfigürasyonlarında ayarlandığı şekilde günlüğe kaydeder. Hata alırsak projelerimizi doğru şekilde haritalamamışız demektir.

moon project client çalıştırdığımızda beklenen çıktı.

 MÜŞTERİ 

kimlik: müşteri
Kaynak: uygulamalar/istemci
Kök: ~/Projeler/estore/apps/client
Dil: JavaScript
Tür: Uygulama
isim: müşteri
Açıklama: Estore ön uç istemci uygulaması
Sahip: @estore/client
Bakımcılar:
 - <client.project.maintainer>
Kanal: #ay

 GÖREVLER 

yapı: vite yapı
dev: vite --port 3000
biçim: daha güzel --write .
kurulum: pnpm kurulumu
tiftik: eslint --ext .js,.vue --ignore-path .gitignore --fix src

 DOSYA GRUPLARI 

varlıklar:
 - kaynak/varlıklar/*
 - **/*.{scss,css}
 - **/*.mdx
yapılandırmalar:
 - *.{js,json}
kaynaklar:
 - kaynak/**/*
 - türler/**/*
testler:
 - testler/**/*.test.*
 - **/__testler__/**/*

Projeleri ayda yapılandırma

Moon'daki projeler, her projenin dizininin kökündeki .moon/project.yml veya moon.yml yapılandırma dosyaları aracılığıyla yapılandırılabilir.

.moon/project.yml dosyası, çalışma alanındaki tüm projeler tarafından devralınan grupları ve görevleri yapılandırmada kullanışlıdır. Burası, linting, tip denetimi ve biçimlendirme gibi genel görevleri yerleştirebileceğimiz yerdir.

Projeye özel moon.yml dosyası, projeye özgü dosya gruplarının, görevlerin ve bağımlılıkların tanımlanması ve yapılandırılmasında kullanışlıdır.

Bu iki yapılandırma dosyası isteğe bağlıdır ve ayrı ayrı veya birlikte kullanılabilir. Bizim durumumuzda, ikisini de kullanacağız.

.moon içindeki global konfigürasyon dosyasından başlayarak, iki projemizi ekleyerek onlara client ve server kimliklerini verin.

 projeler:
  istemci: 'uygulamalar/istemci'
  sunucu: 'uygulamalar/sunucu'

Node.js, paket yöneticisi ve VCS ayarlarını güncelleyin.

 düğüm:
  sürüm: '16.16.0'
  # "npm" (varsayılan), "pnpm" veya "iplik" seçeneklerinden herhangi biri.
  paket Yöneticisi: 'pnpm'
  # Kullanılacak paket yöneticisinin sürümü (yukarıda).
  pnpm:
    sürüm: '7.8.0'
vcs:
  # Depoyu yönetirken kullanılacak yönetici/ikili dosya.
  # "git" veya "svn" kabul eder. Varsayılan "git" şeklindedir.
  yönetici: 'git'

Görevleri yapılandırma

Yukarıda açıklanan iki yapılandırma dosyasında olduğu gibi, global görevleri .moon/workspace.yml içine yerleştirebiliriz. Projelerimizde, diğer birçok projede olduğu gibi, buraya görev olarak yerleştirilebilecek komut dosyaları, çoğu proje için büyük olasılıkla eşanlamlı olduklarından, linting ve formatlama gibi komut dosyalarıdır.

Bu nedenle, bu görevleri ekleyerek bu dosyayı güncelleyeceğiz.

 görevler:
  # Görevin adı.
  biçim:
    # Sisteminizdeki ikili/komutun adı.
    komut: 'daha güzel'
    # Görev yürütülürken komut satırına iletilecek argümanların listesi.
    argümanlar: '--yaz .'
    # Çalıştırılacak komutun türü ve nerede bulunacağı.
    # "düğüm" (varsayılan) veya "sistem"i kabul eder.
    tip: 'düğüm'
  tiftik:
    komut: 'eslint'
    argümanlar:
      - --ignore-path
      - .gitignore
      - --düzeltmek
      - kaynak
    tip: 'düğüm'

Yukarıdaki yapılandırmadan, görevlerin bir adı, argümanları ( args ) ve bir türü olduğunu görebiliriz. Daha sonra daha fazla seçenek göreceğiz ve görev seçeneklerinin tam listesi için bunları ayın belgelerinde görebilirsiniz.

Ayın özelliklerinde bahsedildiği gibi, burada görevlerin ayrıntılı konfigürasyonuyla tanışıyoruz.

Ayrıca bireysel proje komut dosyalarını ay görevlerine dönüştüreceğiz.

server projesiyle başlayarak.

 # apps/sunucu/moon.yml

---
tip: "uygulama"
dil: javascript
proje:
  isim: "sunucu"
  açıklama: "Estore'un arka uç sunucu uygulaması"
  kanal: "#ay"
  sahip: "@estore/server"
  bakıcılar: ["server.project.leader"]
görevler:
  tiftik:
    komut: "eslint"
    argümanlar:
      - --harici
      - .js
    tip: "düğüm"
    seçenekler:
      mergeArgs: "başa ekle"
  tohum:
    komut: düğüm
    argümanlar:
      - prizma/tohum
    deps:
      - "~:init"
    tip: düğüm
  içinde:
    komut: pnpm
    argümanlar:
      - dlx
      - prizma
      - göç
      - dev
      - "--isim"
      - içinde
    tip: düğüm
  geliştirici:
    komut: düğüm
    deps:
      - "~:tohum"
      - "~: tiftik"
      - "~:biçim"
    seçenekler:
      outputStyle: "akış"
    tip: düğüm
  servis:
    komut: düğüm
    argümanlar:
      - "src/index.js"
      - "NODE_ENV=üretim"
    deps:
      - "~:init"
    tip: düğüm

Bu yapılandırma dosyasında daha fazla görev seçeneği görebiliriz.

Burada, "stream" olarak ayarlanan options.outputStyle , görev çalışırken doğrudan konsola çalıştırılan görevden çıktı günlüğünün akışını sağlar.

deps ayarı, bir görevi veya daha fazlasını başka bir görevin bağımlılığı olarak kullanmamıza izin verir.

"prepend" olarak ayarlanmış options.mergeArgs , bu görevdeki argümanları global proje konfigürasyonu .moon/project.yml içindeki karşılığına bir önek olarak ekler. Bu nedenle, bu belirli projede çalıştırıldığında "lint" görevinin tam komut dosyası aşağıdaki gibi olacaktır.

 tiftik:
    # Sisteminizdeki ikili/komutun adı.
    komut: 'daha güzel'
    # Görev yürütülürken komut satırına iletilecek argümanların listesi.
    argümanlar:
      - --harici
      - .js
      - --ignore-path
      - .gitignore
      - --düzeltmek
      - kaynak
    # Çalıştırılacak komutun türü ve nerede bulunacağı.
    # "düğüm" (varsayılan) veya "sistem"i kabul eder.
    tip: 'düğüm'

Bu, aynı görevin, bu durumda "lint" 'in çalıştırıldığı projeye bağlı olarak farklı dosya türlerine uygulanması gerekebileceği durumlarda çok kullanışlıdır.

Bu yapılandırma dosyası aynı zamanda bize project ayarı aracılığıyla aşağıdaki örnekte görüldüğü gibi proje meta verilerini ayarlama katmanı sağlar.

client proje yapılandırmasını aşağıdaki ayarlarla sonlandırın.

 tip: "uygulama"
proje:
  isim: "müşteri"
  açıklama: "Estore'un ön uç istemci uygulaması"
  kanal: "#ay"
  sahip: "@estore/client"
  bakıcılar: ["client.project.lead"]
dil: javascript
görevler:
  tiftik:
    komut: 'eslint'
    argümanlar:
      - --harici
      - .js,.vue
    tip: 'düğüm'
    seçenekler:
      mergeArgs: 'başa ekle'
  geliştirici:
    komut: vite
    argümanlar: "--port 3000"
    deps:
      - "~: tiftik"
      - "~:biçim"
    seçenekler:
      runInCI: yanlış
      outputStyle: "akış"
    tip: düğüm
  inşa etmek:
    komut: vite
    argümanlar:
      - inşa etmek
    deps:
      - "~: tiftik"
      - "~:biçim"
    tip: düğüm
  Ön izleme:
    komut: vite
    argümanlar:
      - Ön izleme
    tip: düğüm

Yukarıdaki yapılandırmayı gözlemleyerek, istemci projesi için "lint" görevine uygulanan değişiklikleri görebiliriz.

estore gördüğümüz gibi, her iki projede de var olan ve bazıları bir projeye özel olan bağımlılıklar var. package.json dosyalarını güncelleyebilir, global bağımlılıkları çalışma alanı kökünün package.json dosyasına ekleyebilir ve projeye özel package.json dosyalarından kaldırabiliriz.

Artık bağımlılıkları kurmak için npm install çalıştırabiliriz. Ve çalışma alanımızı doğru bir şekilde yapılandırdıysak, bağımlılıklar uygun konumlarına kurulacaktır: çalışma alanı kökündeki genel bağımlılıklar ve ilgili proje kökleri içindeki projeye özel bağımlılıklar.

Daha sonra projelerimizi uygulanabilir tüketim seviyelerine göre değiştirmeye devam edebiliriz. Kaynak kodunun tamamı estore'un GitHub deposunda bulunabilir.

Ardından, değişiklikleri sahneleyin ve uygulayın. Ayrı projelerin Git geçmişlerinin tanımlanmasını basitleştiren, ancak aynı zamanda bir bütün olarak depoda tutarlı bir akış gösteren bir taahhüt gönderme biçimi seçin. (Ya da sadece estore deposundaki kodu kullanabilirsiniz)

Her şey ayarlandığında, moon run komutu ile yapılandırılan görevleri yürütebiliriz.

Görevler iki şekilde yürütülebilir:

a. moon run <project-id>:<task-name> olan bir proje kapsamında

Depomuzdan, build görevini apps/client içinde aşağıdaki gibi çalıştırmak için komutun bu biçimini kullanabiliriz.

 ay çalıştırma istemcisi: inşa

b. Ayrıca bu moon komutuyla bir monorepodaki tüm projelerde yürütülecek görevleri global olarak çalıştırabiliriz: moon run :<task-name> . Örneğimizden, her iki projenin de formatlanması ve linted olması için tiftik ve format görevlerini bu şekilde çalıştırabiliriz.

 ay koşusu :format 

Bağımlılık görevlerini çalışırken görmek için, çalışma alanımızda moon run client:dev deneyin. Bu komut lint ve format komutlarına bağlı olduğundan, bu iki görevin de dev göreviyle bağlantılı olarak çalıştığını göreceksiniz.

Ay nispeten yeni olmasına rağmen, repoları yönetme konusunda harika bir iş çıkarıyor. Yukarıdaki örnekte de görebileceğimiz gibi, ayın düzgün bir öğrenme eğrisi vardır. Gelişimini gözlemleyerek ve aktif geliştirme ekibinin özelliklerini görerek, ileriye dönük çok şey vaat ediyor.

Projeye dahil edilen yeni özellikleri görmek için ayın değişiklik günlüğünü ziyaret ettiğinizden emin olun. Şu anda, iki haftada bir programa yeni özellikler ekleniyor.

Özet

Ay'ın özelliklerine ve kavramlarına yönelik bu kapsamlı girişte, gerçek hayattan bir örnek kullanarak (bu durumda, bir e-ticaret web uygulamasının geliştirilmesi), aşağıdakileri ele aldık:

  • Ay nedir ve temel özellikleri
  • Çoklu depo kurulumundan monorepo nasıl kurulur ve ay ile yönetilir
  • Aydaki çalışma alanları nasıl yapılandırılır ve bir monorepo kurulumunda birden çok proje nasıl yönetilir
  • Verimli sonuçlar elde etmek için ay görevleri nasıl oluşturulur ve çeşitli seçeneklerle nasıl çalışır?

Görev önbelleğe alma ve yalnızca etkilenen kod üzerinde çalıştırma gibi özelliklerle, diğer birçok derleme sistemi gibi moon, her tür proje için (hem çoklu repo hem de monorepo) yararlı sayılabilir, çünkü bu tür özellikler düzenli olarak bulunmayan bir verimlilik sağlar. paket yöneticileri gibi araçlar.

Monorepo kurulumlarının, kod ve araçlardan daha fazlası olduğu için organizasyona ve kod hakkında nasıl düşündüğümüze değişiklikler getirdiğini kabul ediyoruz. Buna karşılık, tutarlılık eklemek, yeni projeler oluşturmakla ilgili ek yükü azaltmak, büyük ölçekli yeniden düzenleme yapmak, kod paylaşımını ve işbirliğini kolaylaştırmak vb. gibi avantajlar elde ederiz. Genel olarak, aksi takdirde karmaşık projelerde verimli çalışmayı teşvik ederler.

Ve bu özel noktada, ay, nispeten emekleme aşamasında olmasına rağmen, diğer yapı sistemlerinin şu anda sunmadığı aşağıdaki araçları sunar:

  • Tüm makinelerde Node.js'nin aynı sürümlerinin, paket yöneticilerinin (npm, iplik, pnpm) ve diğer araçların kullanılmasını sağlayan entegre bir araç zinciri tutarlı ve tekrarlanabilir yapılar sağlar
  • Çalışma alanı genelinde kolay görev bildirimi ve devralma. Global görevler, bir çalışma alanındaki tüm projelerde çalışacak şekilde tanımlanabilir ve bireysel projelerin ihtiyaçlarına göre daha fazla değiştirilebilir. Bunun bir gösterimini estore örneğimizde gördük
  • package.json bağımlılıkları ve tsconfig.json proje referansları gibi yaygın JavaScript sorunlarının otomasyonu
  • Sürekli entegrasyon (CI) için birinci sınıf destek

Moon'un diğer ana yapı sistemleriyle karşılaştırmasını burada bulabilirsiniz .

Derin bir dalış yapmak ve ay, kavramları, sundukları ve daha fazla örnek hakkında daha fazla bilgi edinmek için ayın resmi belgelerini ziyaret edebilirsiniz.

LogRocket Blog'da ilk olarak Moon ile repo yönetimini iyileştirin yazısı çıktı.

etiketlerETİKETLER
Üzgünüm, bu içerik için hiç etiket bulunmuyor.

Sıradaki içerik:

Moon ile repo yönetimini iyileştirin