node.js - Dahili bağımlılığı olan bir yarn workspace monoreposundan NPM paketi oluşturma

Yarn workspace kullanarak NPM’de yayınlanacak bir kütüphane geliştiriyorum. Kütüphane, aynı çalışma alanında bulunan özel bir core pakete bağımlı. Anladığım kadarıyla, çalışma alanı kütüphaneye çalışma alanındaki bağımlılığı dahil etmeli. Core paket, kütüphanenin devDependency olarak listelenmiş durumda.

Sanırım Yarn workspaces belgelerine göre çalışma alanını ve paketleri doğru şekilde ayarladım.

Sorunumu bir örnek olarak yeniden yarattım. İşte benim depom ve işte NPM kayıt defterindeki paket

Bir uygulamaya kütüphaneyi yüklediğimde Error: Module not found: Error: Can't resolve 'jakelo123-core' in '/Users/jakeloew/chalk/fusionauth/angular-quickstart/complete-application/node_modules/jakelo123-user-lib/dist' hatasını alıyorum -- iç bağımlılığı içeren modül bulunamadı.

Cevap #1

Benim anladığım kadarıyla, çalışma alanı, çalışma alanından olan bağımlılığı kütüphaneye dahil etmelidir.

Bu doğru değil. "bundling" ne TS ne de paket yöneticisi tarafından sağlanmaktadır. Eğer buna ihtiyacınız varsa, dahil etmeniz ve yapılandırmanız gereken bir şeydir.

Çalışma alanları, kaynak ağacında birden çok paketi manuel olarak sembolik linklerle bağlamaya veya garip bağımlılık yönetimi yapmaya gerek kalmadan geliştirmek ve düzenlemek için hoş bir yoldur. Herhangi bir türden derleyici değillerdir.

Çekirdek paket, kütüphanenin bir geliştirici bağımlılığı (devDependency) olarak listelenmiştir

Yukarıdaki gibi bir paketleme olmadığından ve çekirdek bağımlılık devDependencies'te bulunduğundan, ona bağımlı olan yüklenirken çekirdek bağımlılık alınmaz. Bu yüzden mevcut değildir.

Genellikle, bu tür paketleme kütüphane tüketicisinin ilgilendiği bir konudur. Bu, her iki paketinizi de inşa edip yayımlayacağınız anlamına gelir. Temel paket, dependencies altında beyan edilir ve devDependencies altında değil. Tüketici genellikle Vite/Webpack/Rollup veya ne kullanıyorlarsa ona göre uygulama düzeyinde paketleme yapar. Ya da yapmayabilirler, bu onlara bağlıdır.

Ancak, bu modülün "özel" olduğunu belirttiniz, bu dikkat çekici. Projelerin aynı yazarın birçok yayımlanmış paketinden oluşması oldukça normaldir, ancak çoğunun doğrudan kullanılma ihtimali düşüktür ve hatta paket düzeyinde belgeleri olmayabilir. Bu yaygındır ve genellikle endişe edilmesi gereken bir durum değildir. Bu durumda, genellikle ortak bir paket kapsamı altında yayımlanırlar, bu da onları ilişkili olarak tanımlamaya yardımcı olur.

Ancak, eğer gerçekten o paketin yayınlanmasını istemiyorsanız, yayınlamadan önce (derleme sırasında) üst düzey modülünüzde bir birleştirme adımına ihtiyacınız olacaktır. Rollup, esbuild veya diğer birçok araçtan birini kullanabilirsiniz.

Not: Bu varsayılan olarak tüm diğer üçüncü taraf bağımlılıkları da paketler, bu da tüketici için pek iyi değildir (tekrarlanan bağımlılıklar, büyük paket boyutu, çözülmesi zor güvenlik sorunları). Ancak bunu, paketleyicinin "externals" özelliklerini kullanarak yapılandırabilirsiniz (esbuild, Rollup).

Düşünmeniz gereken bir diğer şey, bu paketin özel olup olmadığı ve gerçekten yeniden kullanılabilir bir birim olup olmadığıdır. Muhtemelen, bunu ayırmayı tercih ettiyseniz öyledir. Gelecekte, bu temel modüle bağımlı birden fazla modül yayınlamak isterseniz ve bunların hepsini paketlerseniz, herhangi bir tüketici paket yöneticisi, bu üst düzey paketlerden birden fazlasını kullanıyorsa, bu temel bağımlılığı tekilleştiremez. Ve her temel değiştiğinde hepsini tekrar yayınlamak zorunda kalırsınız ki bu rahatsız edici ve oldukça fazla iş gerektirir ve muhtemelen genel olarak daha kötü bir sonuca yol açar.

İşte bu yüzden, genellikle çekirdek modülü de yayınlarsınız, hatta bu iç bir detay olsa bile. Ama buna rağmen paketleme yapmak istemeniz için çok iyi bir gerekçeniz olabilir (ve bazıları vardır), bu yüzden soru geçerliliğini korur. Ancak, onun gerçekten özel olmasını sağlamakla neyi başarmak istediğinizi iyi düşünmelisiniz.