de-approval-v3

Widget persetujuan ERP, dua kelompok:

• widget dokumen untuk layar detail: alur langkah, kartu keputusan, drawer riwayat.
• layar daftar untuk menu Kotak Masuk dan dashboard: de-approval-v3-kotak-masuk (tugas saya), de-approval-v3-dokumen-saya (dokumen yang saya ajukan), de-approval-v3-antrean (antrean seluruh organisasi). Ketiganya butuh peta rute dokumen, dipasang di tagnya lewat [rute-dokumen] — lihat PANDUAN-PASANG.md §2.3.

Dipasang berdampingan dengan paket persetujuan sebelumnya; paket lama tidak disentuh.

Pakai

import { ApprovalV3Module } from 'de-approval-v3';

@NgModule({ imports: [
  ApprovalV3Module.forRoot({
    alamat: environment.srv_approval_v3,
    ambilToken: () => localStorage.getItem('auth_token') || '',
  }),
] })

Lalu di template:

<de-approval-v3-alur-tegak [kunci-modul]="\"purchase_request\"" [id-dokumen]="id"></de-approval-v3-alur-tegak>
<de-approval-v3-aksi-kartu [kunci-modul]="\"purchase_request\"" [id-dokumen]="id" (hak-berubah)="boleh = $event"></de-approval-v3-aksi-kartu>

Gaya: lihat CATATAN-GAYA.md — paket ini mensyaratkan gaya ERP global.

Panduan lengkap

Peta rute dokumen dan urutan kekhususannya, komponen layar daftar, peringatan bentrok nama ApprovalV3Module di erp_master, cara pasang di modul lain dan di micro frontend lain, daftar Input/Output, serta masalah yang sering muncul: PANDUAN-PASANG.md.

JANGAN PAKAI 0.2.0, 0.2.2, MAUPUN 0.2.4

0.2.0 terbit di npm pada 6 Okt 2026 03:09 UTC dari build yang dibuat sebelum putaran perbaikan selesai. Ia tidak boleh dipakai.

Satu cacat yang akan dilihat SETIAP pemakai, pada setiap pemakaian: tombol Ingatkan di de-approval-v3-dokumen-saya menampilkan kotak kuning peringatan pada pengingat yang BERHASIL. Isinya keluhan tentang kredensial FCM. Pengingatnya benar-benar terkirim, loncengnya benar-benar tertulis, dan pemakai tetap membaca "kanal luar gagal". Sebabnya: jawaban sukses membawa galat_kanal yang hampir selalu terisi (push ikut diminta sementara kredensial FCM belum dipasang), dan 0.2.0 menaikkan setiap isinya menjadi peringatan. Pemakai yang menekan tombol lalu melihat kotak kuning menyimpulkan sistemnya rusak — dan itu kesimpulan yang lebih mahal daripada fiturnya.

Satu cacat kedua, jarang tetapi menyesatkan: bila pusat notifikasi melaporkan nol kiriman, 0.2.0 berkata "Slot langkah ini kemungkinan belum punya pemegang". Sebab itu mustahil — langkah tanpa penerima dijawab 409 APP-10 sebelum pengiriman — jadi kalimat itu mengirim pembacanya mengejar sebab yang tidak mungkin.

Sisa selisihnya dokumentasi, dan dokumentasi ikut terbit di dalam paket: 0.2.0 memuat PANDUAN-PASANG.md dan README.md versi lama, termasuk docblock yang menjelaskan mesin yang sudah tidak ada (pembatas harian yang sudah pindah ke kunci idempoten pusat, tombol yang disebut "menulis satu baris lonceng" padahal mengirim surel dan push, dan tabel 409 yang kurang dua baris). Siapa pun yang membaca paket terpasang 0.2.0 untuk memutuskan di mana menaruh tombolnya akan membaca keterangan yang salah.

Yang TIDAK cacat di 0.2.0, supaya tidak ikut disalahkan: [rute-dokumen] dan peta rute enam modul purchasing sudah benar di sana, dan teks di layar soal pemeta rute juga sudah benar.

Kenapa ada lubang di urutan versi

Versi npm yang sudah terbit tidak bisa ditimpa. Menerbitkan ulang 0.2.0 dijawab 403 You cannot publish over the previously published versions. Yang bisa dilakukan hanya menandainya sebagai usang (npm deprecate, lihat di bawah) dan menerbitkan versi baru. Itu sebabnya perbaikannya keluar sebagai 0.2.1, bukan sebagai 0.2.0 yang diperbaiki.

Rentang versi di aplikasi pemakai

Pakai ^0.2.7:

-    "de-approval-v3": "^0.1.0",
+    "de-approval-v3": "^0.2.7",

Batas bawahnya yang penting, bukan hanya versi terbarunya. Pada 0.x caret menahan minor tetapi tidak menahan patch, jadi:

| Rentang | Yang diizinkan | Termasuk yang usang? | |---|---|---| | ^0.2.0 | >=0.2.0 <0.3.0 | ya — 0.2.0, 0.2.2, 0.2.4 | | ^0.2.4 | >=0.2.4 <0.3.0 | ya — 0.2.4 itu sendiri | | ^0.2.6 | >=0.2.6 <0.3.0 | tidak — tetapi 0.2.6 masih memuat cacat penyegaran sesudah keputusan | | ^0.2.7 | >=0.2.7 <0.3.0 | tidak |

npm install di mesin yang lockfile-nya belum ada boleh memilih versi usang mana pun yang masih masuk rentang. Jadi setiap kali satu versi ditandai usang, rentang di aplikasi harus ikut naik — menaikkan versi paket saja tidak menutup jalannya.

0.2.2 dan 0.2.4 juga tidak boleh dipakai — dan sebabnya BUKAN kode

Keduanya terbit pada 7 Okt 2026 dari akar repo, bukan dari ./dist. Isinya src/lib/**.ts, tsconfig.json, dan ng-package.json, tanpa esm2020/, fesm2015/, fesm2020/, dan tanpa satu pun .d.ts: aplikasi yang memasangnya tidak punya apa pun untuk diimpor. Penandanya pasti — package.json di dalam tarball memuat 11 devDependencies, sementara tarball yang dibungkus dari ./dist memuat 0.

Jebakannya sudah tertulis di bagian "Merawat paket ini" di bawah sejak 0.2.1, dan tetap menggigit dua kali. Isi 0.2.2 keluar sebagai 0.2.3; isi 0.2.4 keluar sebagai 0.2.5.

Sejak 0.2.5 penjaganya bukan lagi dokumen: prepublishOnly menjalankan skrip/penjaga-terbit.js, yang menolak npm publish kecuali dijalankan lewat npm run terbit. Peringatan di dokumen sudah terbukti tidak cukup.

Periksa tarballnya sebelum publish, dua perintah dan keduanya murah:

tar -tzf de-approval-v3-0.2.7.tgz | grep -c "^package/fesm2020/"

tar -tzf de-approval-v3-0.2.7.tgz | grep -c "^package/src/"

Yang pertama harus bukan nol; yang kedua harus nol.

Merawat paket ini — build & terbitkan ke npm

Bagian ini untuk yang merawat paket, bukan yang memakainya (yang memakai: PANDUAN-PASANG.md).

Setiap butir di bawah pernah benar-benar menggigit, bukan kehati-hatian teori.

Urutannya

Komentar tidak ditulis di baris perintah di dokumen ini — lihat "Jangan tempel #" di bawah.

Satu perintah, dan inilah satu-satunya jalur terbit yang diterima penjaga (OTP 2FA akan diminta):

npm run terbit

Ia membangun dengan CI=1, membungkus dari ./dist, memeriksa isi tarballnya, lalu menerbitkan. Nama tarballnya diambil dari versi di package.json, jadi tidak ada nama yang perlu disesuaikan tangan.

Untuk memeriksa tanpa menerbitkan apa pun — inilah yang dijalankan saat menyiapkan rilis:

CI=1 npm run build

npm pack ./dist

npm run periksa-tarball

npm run periksa-kontrak mencetak kontrak Input/Output tiap komponen dari dist/fesm2015 — termasuk yang DIWARISI dari kelas dasar, yang tidak terbaca dari .d.ts — lalu menolak bila pewarisannya patah. Dengan folder aplikasi sebagai argumen ia juga mencocokkan binding aplikasi dengan kontrak itu. Alasannya: Angular mendiamkan binding ke Input/Output yang tidak ada, jadi satu huruf salah ketik mematikan satu fungsi tanpa galat apa pun.

npm run periksa-tarball memeriksa tarball versi sekarang: ada fesm2020, ada .d.ts, nol berkas package/src/, nol devDependencies, versi di dalam tarball sama dengan versi di repo, dan rentang versi yang dianjurkan PANDUAN-PASANG.md serta README.md di dalam tarball sama dengan versi yang sedang diterbitkan. Keluar bukan-nol bila salah satu gagal.

Pemeriksaan terakhir itu ada karena tarball 0.2.5 masih menganjurkan ^0.2.4: dokumen yang ikut terbit adalah instruksi pemasangan, dan instruksi yang menunjuk versi usang sama buruknya dengan kode yang rusak. Jadi ia diperlakukan seperti kode, bukan diingat tangan.

npm publish yang dijalankan langsung dari akar repo ditolak oleh prepublishOnly — itu yang menutup lubang 0.2.2/0.2.4.

1. Terbit dari ./dist, BUKAN dari akar repo

package.json di akar repo adalah berkas pengembangan; yang terbit adalah dist/package.json yang dibuat ng-packagr. Keduanya berbeda, dan angkanya memperlihatkannya:

| | devDependencies | isi | |---|---|---| | package.json di akar | 11 | sumber TypeScript, scripts, tsconfig | | package/package.json di dalam tarball | 0 | hasil kompilasi: esm2020/, fesm2015/, fesm2020/, *.d.ts |

Menerbitkan dari akar repo berarti mengirim repo sumber tanpa hasil kompilasi, dan pemakainya mendapat paket yang tidak bisa diimpor — main/module/typings menunjuk berkas yang tidak ada di dalamnya. ng-packagr juga sengaja membuang scripts dan devDependencies saat menulis manifest terbit; kalau Anda menerbitkan dari akar, pembuangan itu tidak pernah terjadi.

2. CI=1 wajib untuk build

Tanpa CI=1, ng-packagr memakai cache di node_modules/.cache/ng-packagr dan build gagal:

✖ Compiling with Angular sources in Ivy partial compilation mode.
ENOENT: no such file or directory, rename
'…/node_modules/.cache/ng-packagr/tmp/d346ed79' -> '…/node_modules/.cache/ng-packagr/content-v2/sha512/…'

CI=1 mematikan cache itu. Diverifikasi di repo ini: npm run build tanpa CI=1 menghasilkan galat di atas, dan CI=1 npm run build lulus pada repo yang sama tanpa perubahan lain.

3. npm publish dist tanpa ./ akan mengunduh paket orang lain

dist tanpa ./ dibaca npm sebagai nama paket di registry, bukan folder. Dan paket bernama dist memang ada di registry (npm view dist version → 0.1.2), jadi npm akan dengan senang hati mengunduhnya dan Anda tidak mendapat peringatan apa pun. Sudah pernah terjadi di repo ini dengan npm pack dist.

Selalu ./dist. Atau lebih baik: terbitkan tarballnya (butir 4).

4. Cara paling aman: terbitkan TARBALL-nya, bukan ./dist

npm publish de-approval-v3-0.2.7.tgz

Alasannya bukan selera. dist dihapus-dan-dibuat-ulang di awal setiap build, sementara tarball adalah artefak beku. Pemilik sudah kehilangan dist di tengah penerbitan hari ini karena ada build lain berjalan di folder yang sama — npm publish ./dist yang separuh jalan lalu kehilangan foldernya adalah kegagalan yang membingungkan, dan pada waktu yang salah bisa menerbitkan isi yang tidak lengkap.

Dengan tarball: apa yang Anda periksa persis apa yang terbit. Isinya bisa dilihat dulu tanpa menerbitkan apa pun:

tar -tzf de-approval-v3-0.2.7.tgz

5. Jangan tempel # di baris perintah

INTERACTIVE_COMMENTS mati di zsh pemilik, jadi # dan sesudahnya diteruskan sebagai argumen. npm publish x.tgz # terbitkan menjadi npm publish x.tgz '#' terbitkan, dan npm membaca # sebagai nama tag:

npm ERR! Invalid tag name "#"

Itu sebabnya tidak ada satu pun komentar # di baris perintah dalam dokumen ini. Komentar ditulis di baris terpisah, di atas perintahnya — supaya perintahnya tetap aman disalin-tempel utuh.

6. OTP 2FA, dan versi yang terbit tidak bisa ditimpa

npm publish akan meminta OTP dari aplikasi autentikator. Untuk tanpa prompt:

npm publish de-approval-v3-0.2.7.tgz --otp=123456

Versi npm yang sudah terbit TIDAK BISA ditimpa. Menerbitkan ulang versi yang sama dijawab 403 You cannot publish over the previously published versions. Yang bisa dilakukan hanya npm deprecate (memberi peringatan, paketnya tetap bisa diunduh) atau menerbitkan versi baru. Jadi periksa tarballnya sebelum publish, bukan sesudah.

Versi yang sudah ada di registry bisa dilihat dengan:

npm view de-approval-v3 versions

Dan isi persis yang terbit untuk satu versi — berguna untuk memastikan yang terbit memang yang Anda maksud:

npm view [email protected] dist.shasum dist.fileCount

Cocokkan shasum itu dengan yang dilaporkan npm pack ./dist sebelum Anda menerbitkannya. Kalau berbeda, yang terbit bukan build yang Anda periksa.

7. Menandai satu versi sebagai USANG (npm deprecate)

Ini satu-satunya cara memperingatkan pemakai tentang versi yang sudah terbit, karena versi terbit tidak bisa ditimpa maupun dihapus.

Perintahnya, dengan pesan sebagai argumen terakhir:

npm deprecate [email protected] "0.2.0 menampilkan peringatan palsu pada setiap Ingatkan yang berhasil; pakai 0.2.1"

Dan untuk 0.2.2 serta 0.2.4, yang terbit tanpa hasil kompilasi:

npm deprecate [email protected] "0.2.2 terbit dari akar repo dan tidak memuat hasil kompilasi; pakai 0.2.3 atau lebih baru"

npm deprecate [email protected] "0.2.4 terbit dari akar repo dan tidak memuat hasil kompilasi; pakai 0.2.5 atau lebih baru"

PESANNYA TAMPIL DI TERMINAL SETIAP ORANG YANG MEMASANG PAKET INI, pada setiap npm install yang menyentuh versi itu — bukan hanya sekali, dan bukan hanya bagi yang mencarinya. Jadi tulis pesan yang berguna: sebutkan apa yang rusak dan versi mana yang dipakai sebagai gantinya. "Jangan dipakai" memberi tahu pembacanya bahwa ada masalah tanpa memberi tahu apa dan harus ke mana, dan ia akan membuka isu untuk menanyakannya.

Rentang versi juga bisa diberi tanda, mis. de-approval-v3@"<0.2.1". Hati-hati: tanda kutipnya wajib, karena < adalah pengalih keluaran di shell.

Menghapus tandanya: jalankan ulang dengan pesan kosong.

npm deprecate [email protected] ""

npm deprecate juga meminta OTP seperti publish.

Sesudah terbit

Aplikasi pemakai perlu menaikkan rentang versinya sendiri: ^0.1.0 tidak mengizinkan 0.2.x (aturan caret pada versi 0.x). Diff-nya ada di PANDUAN-PASANG.md §9.

Mengubah dokumen pun MENUNTUT build ulang

PANDUAN-PASANG.md dan CATATAN-GAYA.md terdaftar sebagai assets di ng-package.json, jadi keduanya ikut terbit di dalam paket. Mengubah salah satunya tanpa CI=1 npm run build + npm pack ./dist berarti tarball Anda masih memuat dokumen yang lama. Perlakukan dokumen seperti kode: ubah, bangun, bungkus, baru terbitkan.