thảo luận Quá chán với đống dependencies của Javascript, công ty mình dần chuyển về MVC

mình cũng chưa bao giờ dùng npm ci luôn.

Bình thường add 1 package mới thì đơn giản dùng npm install hoặc yarn add thôi, y như cú pháp mà người làm ra nó hướng dẫn. Project của mình dùng theo kit từ 2018 nên đã dùng yarn để install mỗi khi có update vào package.json và tất cả những lần như thế, version của thư viện hay lib mới add vào đều theo version của người đầu tiên install hay add nó vào, ko bao giờ có chuyện lệch cả.

Từ khi bắt đầu project từ node 8 đến vài năm sau khi lên node 14 thì cũng chỉ sửa một chút ở webpack config, tăng version của 1 số lib đang dùng và chỉ sửa code liên quan đến 1 lib duy nhất, gần như 99% code là ko bị ảnh hưởng gì, vẫn chạy tốt.
 
Cho mình hỏi thêm ngoài lề chút, bên mình cái mô hình app và Database (DB) tách biệt nhau, thì docker có thể đảm bảo được đồng nhất cái tầng app. Tuy nhiên cái DB con product thì làm cách nào để đồng nhất dc với bên DEV nhỉ? Lúc update phải chạy các script riêng để tạo bảng phát sinh, hay package stored procedure mới cho DB Nên cực và rủi ro nhất là phần cập nhật cho DB
Tại DEV dùng 1 DB riêng máy yếu, dữ liệu thô sơ test còn thằng product thì dùng DB xịn hơn, dữ liệu khổng lồ thực tế bên khách hàng. Khi bên DEV đưa phiên bản update app, nó có cả update luôn cấu trúc DB các stored chạy dưới DB nữa, lỗi thì hay phát sinh ngay tầng DB này, và tầng DB này chứa Business logic khá nhiều. Cụ thể luôn DB mình đang dùng là Oracle
Đọc thì có vẻ bên bạn ko xài ci/cd phải ko?
 
đúng là tuổi trẻ chưa trải sự đời, mà dự rằng trong cty cũng không có ông senior FE nào, chứ nếu có thì ổng lại vả cho thớt tỉnh ra mới thôi
 
Đọc thì có vẻ bên bạn ko xài ci/cd phải ko?
Đúng rồi, chưa áp dụng được, tại như vấn đề nói trên, bên mình tầng app và DB tách biệt nhau, nên lúc cập nhật vừa app vừa DB không biết thiết kế CI/CD kiểu gì
 
Đúng rồi, chưa áp dụng được, tại như vấn đề nói trên, bên mình tầng app và DB tách biệt nhau, nên lúc cập nhật vừa app vừa DB không biết thiết kế CI/CD kiểu gì
Thì chạy migration xong rồi start container thôi
 
hóng bác chia sẻ thêm, trước 1 số dự án outsource mình toàn npm install package name :shame: :shame:
Ý thím kia là bước cài dependencies đã khai báo và lock, như cái link bên dưới ấy thím chứ không phải là kiểu npm install abcxyz gì đâu, cái thím nói là đang add dependency mới rồi. Ví dụ giờ đổi qua máy mới, thím clone project về thì phải chạy npm i 1 cái cho nó có cái thư mục node_modules rồi mới chạy được ấy, cái đó mới là cái thím trên kia nói.

Chạy trên CI thì mỗi lần chạy có khi trên 1 node khác nhau nên trong pipeline phải có bước restore dependencies rồi mới build. Vậy nên là chuyện đảm bảo có thể reproduce cái environment trên nhiều máy là rất quan trọng, nếu không có khi lúc cài ở máy thím nó là version này nhưng qua CI nó cài version khác mất rồi, lúc đó thì sẽ ra mấy cái vấn đề như thím thớt #1. Không có CI thì chạy trên máy dev khác vẫn có thể gặp vấn đề này.

 
Last edited:
Chuyện này thực tế làm thế nào để đạt đc vậy bạn? Bên mình cũng có vấn đề như bạn trên. Nhưng cty nhỏ, budget hạn chế, hệ thống product 8 triệu khách hàng là đã quá chi phí rồi, con staging không có cách nào làm y con chính đc, do hạn chế hệ thống. Mình đang nói DB thui nha
giống nhất có thể thôi thím, data hoặc infra có thể khác nhưng cấu trúc chắc chắn phải giống
 
Thấy mấy ông hay shit FE work rồi đụng đến FE ko biết làm đổ thừa tùm lum. Rồi code chắc ko có test nên mỗi lần update thư viện là nín thở ko biết break chỗ nào.

Tương tự mấy cái project BE cũng vậy thôi. Có mấy cái project legacy, no test, no document có ai dám update version package đâu, vô sửa chọt chọt chỗ này chỗ kia rồi chạy thôi.
 
1) số 4 ko phải là ko biết lock files, làm NPM mà ko biết lock file thì có đáng bị chửi là éo biết ccc gì ko?
2) số 3 thể hiện kiến thức JS ecosystems kém đấy, nó cũng củng cố cho cái ý số 4
3) cái số 1 thể hiện ý kiến chủ quan dựa trên cái mình biết ở MVC xong đi chê Js ecosystems còn gì? Éo quản lý tốt và biết lựa chọn thư viện xong đổ lỗi cho hẹ thống

Và nhìn chung cảm giác là do éo biết lock file là chính, dẫn đến liên tục gặp lỗi khi install rồi đổ cho cái này cái kia, ko phải lúc nào cũng cần phải nâng cấp framework hay các lib, kể cả khi có security issue thì cũng cần hiểu nó impact thế nào, và thường cũng sẽ có bản patch cho các version phổ biến
em ơi là e. ng ta bảo là upgrade version. lockfile liên quan quá.
e gặp trường hợp thằng lib chính upgrade xong dính thằng con lỗi chưa
 
em ơi là e. ng ta bảo là upgrade version. lockfile liên quan quá.
e gặp trường hợp thằng lib chính upgrade xong dính thằng con lỗi chưa
Dạ e làm gần chục năm với NPM rồi anh, mấy cái đó e kinh qua hết rồi a.

A hỏi lại người ta đi, cái ý số 4 ko phải ko biết lock file thì là gì?

Nói chung chắc chắn đó là chia sẻ của 1 người ko có nhiều kiến thức, kinh nghiệm liên quan JS ecosystem.
 
em ơi là e. ng ta bảo là upgrade version. lockfile liên quan quá.
e gặp trường hợp thằng lib chính upgrade xong dính thằng con lỗi chưa
Đã chạy theo lockfile mà còn sinh lỗi, bạn gửi thử 1 trường hợp cụ thể lên đây xem nào? Nếu các môi trường giống nhau thì lỗi thế nào đc nhỉ?
 
Nhiều vụ từ lockfile này sinh cũng nhiều chuyện, có trường hợp mỗi ông dev một môi trường khác nhau. Đến khi chạy sinh lockfile thì mỗi ông 1 kiểu, conflict loạn lên khi commit :))) Nên kinh nghiệm là khi vấn đề xung đột môi trường xuất hiện là phải tìm cách để các môi trường của dev phải giống nhau thì đỡ sinh chuyện sau này. Ở đây docker làm khá tốt điều đó
 
Nhiều vụ từ lockfile này sinh cũng nhiều chuyện, có trường hợp mỗi ông dev một môi trường khác nhau. Đến khi chạy sinh lockfile thì mỗi ông 1 kiểu, conflict loạn lên khi commit :))) Nên kinh nghiệm là khi vấn đề xung đột môi trường xuất hiện là phải tìm cách để các môi trường của dev phải giống nhau thì đỡ sinh chuyện sau này. Ở đây docker làm khá tốt điều đó
đã lockfile rồi làm sao sinh ra lockfile 1 kiểu nữa. Khi clone project về thì npm ci sẽ ko tạo ra lockfile mới. Còn install package mới có conflict thì kiểu nhánh A install A vs nhánh B install B. Thì giải quyết là phải resolve conflict, rebase theo nhánh nào commit trước thôi.

Môi trường dev FE thường là mac book thôi. Xưa có 1 vài vấn đề mac m1 thôi chứ giờ ok.

Còn project cũ or lâu ko cập nhật thường 6 tháng trở lên, thì BE vs FE đều sợ chuyện install update package nếu ko có viết test.
 
đã lockfile rồi làm sao sinh ra lockfile 1 kiểu nữa. Khi clone project về thì npm ci sẽ ko tạo ra lockfile mới. Còn install package mới có conflict thì kiểu nhánh A install A vs nhánh B install B. Thì giải quyết là phải resolve conflict, rebase theo nhánh nào commit trước thôi.

Môi trường dev FE thường là mac book thôi. Xưa có 1 vài vấn đề mac m1 thôi chứ giờ ok.

Còn project cũ or lâu ko cập nhật thường 6 tháng trở lên, thì BE vs FE đều sợ chuyện install update package nếu ko có viết test.
Đọc reply này đủ biết trình độ, ngô nghê đến buồn cười, nhìn join date ko muốn trả lời luôn.

  • Có lock file rồi thì ko sinh lock file nữa, nhưng chạy npm update thì sẽ update theo môi trường hiện tại nhé. 2 môi trường khác nhau thì việc conflict là có nhé.
  • Cái t nói là cả BE và FE nói chung, còn bạn chỉ biết đến FE lại còn thường dev bằng macbook giờ okay hết rồi thì cũng biết kinh nghiệm thế nào. Thế đã bao giờ gặp lỗi node version khác nhau, npm version khác nhau chạy compress phía FE ra lỗi browser hoặc webkit ko hỗ trợ chưa :LOL: nó chẳng loeen quan đến môi trường luôn
 
Last edited:
Chơi voz chưa nghe vụ bị KIA à :))) Thích thì bỏ tiền ra mua cái acc 2010 thì chắc lời nói sẽ có trọng lượng hơn?
Đọc reply này đủ biết trình độ, ngô nghê đến buồn cười, nhìn join date ko muốn trả lời luôn.

  • Có lock file rồi thì ko sinh lock file nữa, nhưng chạy npm update thì sẽ update theo môi trường hiện tại nhé. 2 môi trường khác nhau thì việc conflict là có nhé.
  • Cái t nói là cả BE và FE nói chung, còn bạn chỉ biết đến FE lại còn thường dev bằng macbook giờ okay hết rồi thì cũng biết kinh nghiệm thế nào. Thế đã bao giờ gặp lỗi node version khác nhau, npm version khác nhau chạy compress phía FE ra lỗi browser hoặc webkit ko hỗ trợ chưa :LOL: nó chẳng loeen quan đến môi trường luôn
cái thứ nhất tui cũng nói rõ là khi nào add thêm or update nó mới đổi nhưng nó chỉ thay đổi những cái liên quan đến package mới thay đổi là chính chứ mấy cái cũ ít đổi, có thể liên quan đến dep kiểu thằng mới nó có thể require cái đã có sẵn thôi. Môi trường hiện tại là cái gì nhỉ, thường 1 số pkg nó có build thêm binary thôi. Như tui có nói mac m1 hồi mới ra 1 số pkg ko build binary cho arm dc.

Lúc commit review code phải nhìn changes trong lock file mới cho chắc. Mà căn bản lockfile và lệnh install của npm ngu hơn yarn thôi. Xài Yarn thì chả bao giờ lo nó tự update version nhảm luôn. Sau này lockfile npm mới đỡ ngu.
. Thế đã bao giờ gặp lỗi node version khác nhau,

Nếu sợ vụ node engine thì trong package json cũng có set được node version trong package.json đấy, chắc ko thèm set qué. Nói chung mấy cái bug build này nọ từ hồi có lockfile là đỡ lắm rồi đấy. Chứ xưa có cái project node 0.1x gì ấy có lockfile để install quéo đâu phải copy cái node_module với set nvm về đúng node 0.1x để fix. Nó lại liên quan đến legacy project. Chứ giờ project mới setup đủ lockfile node version sợ quéo đâu.

Còn cái FE xài mac thì cứ đi ngó thôi. Chứ giờ mac air rẻ rề. Cty nào nghèo lắm ko $ xài mac thôi chứ tui đi làm giờ 99% xài mac hết rồi. Cty nào ko mua nổi thì thua. tooling dev giờ mac cả mớ. Mấy thằng tây lông thích xài mac nên mấy cái software hỗ trợ mac cả núi.
  • FE ra lỗi browser hoặc webkit ko hỗ trợ chưa

Thì setup sao lỗi ai biết này liên quan đến babel chứ lockfile gì vs xưa hay có cái gì quên mẹ tên rồi,mỗi lần install project cũ nó hay đòi chạy update để nó có cơ sở dữ liệu về browser để lúc webpack build nó loại bớt mấy cái feature của các trình duyệt ko hỗ trợ.
 
@no_political Càng nói càng thể hiện trình độ non nớt :LOL: để anh thông não cho nhóc vài cái này nhé, nói cho tỉnh ra:
Chứ xưa có cái project node 0.1x gì ấy có lockfile để install quéo đâu phải copy cái node_module với set nvm về đúng node 0.1x để fix
Các package js có những cái cần build theo kernel của chip, như trong comment của nhóc có đề cập đến chip m1 thì cũng là các package kiểu này cả. Nhóc đi chơi copy node_modules thì bố cũng lậy thầy về việc fixbug kiểu này.

Còn cái FE xài mac thì cứ đi ngó thôi. Chứ giờ mac air rẻ rề. Cty nào nghèo lắm ko $ xài mac thôi chứ tui đi làm giờ 99% xài mac hết rồi. Cty nào ko mua nổi thì thua. tooling dev giờ mac cả mớ. Mấy thằng tây lông thích xài mac nên mấy cái software hỗ trợ mac cả núi.
Đọc hiểu kĩ comment của anh đi, ở đây là việc chạy compress để tạo các files bundles cho browser, nghĩa là máy phía user sẽ sử dụng file này nhé, đóe phải máy dev đâu mà lôi macbook nọ kia vào. Tầm này chắc chưa từng fixbug cho ie 6 bao giờ nhỉ :LOL: để anh gửi vài lỗi cho nhóc sáng mắt ra nhé.


Còn mấy từ khóa nvm, yarn, babel các kiểu nữa :LOL: mấy cái này anh dùng và fix bug liên quan từ lúc nhóc còn chưa ra trường rồi nhé :LOL:
 
@no_political Càng nói càng thể hiện trình độ non nớt :LOL: để anh thông não cho nhóc vài cái này nhé, nói cho tỉnh ra:

Các package js có những cái cần build theo kernel của chip, như trong comment của nhóc có đề cập đến chip m1 thì cũng là các package kiểu này cả. Nhóc đi chơi copy node_modules thì bố cũng lậy thầy về việc fixbug kiểu này.


Đọc hiểu kĩ comment của anh đi, ở đây là việc chạy compress để tạo các files bundles cho browser, nghĩa là máy phía user sẽ sử dụng file này nhé, đóe phải máy dev đâu mà lôi macbook nọ kia vào. Tầm này chắc chưa từng fixbug cho ie 6 bao giờ nhỉ :LOL: để anh gửi vài lỗi cho nhóc sáng mắt ra nhé.


Còn mấy từ khóa nvm, yarn, babel các kiểu nữa :LOL: mấy cái này anh dùng và fix bug liên quan từ lúc nhóc còn chưa ra trường rồi nhé :LOL:
Nhóc đi chơi copy node_modules thì bố cũng lậy thầy về việc fixbug kiểu này.

Vì project legacy làm quéo gì có lockfile đâu. npm install nó chả break tùm lum. Nói chung những project như vậy 1 là tìm cách install đúng version ko chơi dấu ^, ko dc thì kiếm thằng nào đã từng code xin node_module, ko thì tìm cách migrate thôi.
Project đó xài mac nên hồi đó copy chạy vô tư thôi :go: Chứ cho cả đám xài linux mỗi thằng 1 distro có mà sml. Thêm cái đám window thằng thì wsl thằng thì cài node trực tiếp loạn xạ cả lên. Mà node version 0.1xx là cũ lắm rồi chứ có còn active dev đâu. Lâu lâu vô sửa tý rồi chạy ai rảnh đâu mà đi migrate. Còn hỏi thì cty outsrc nào chả vậy.

Rồi chuyên bundle sai trên IE gì đấy cũng có liên quan đến lockfile đâu. Đó là vấn đề của thằng bundler. Nếu lockfile install đúng version còn nó build ra mà ie6 ếu xài dc thì đó là chuyện của thằng bundler or thằng code ko target đúng browser để bundler nó install đc patch cho những feature mà browser cũ ko support.

Khoe khoang làm lâu làm gì vậy anh :)) giờ công nghệ nó cập nhật hàng ngày ăn thua nhau cập nhật nhanh hay ko thôi :go: Chứ như xưa mớ kiến thức cũ ie, gulp, grunt, bower... giờ còn gì đâu. Như bữa giờ toàn xài webpack, chứ giờ tụi nó chạy qua vite mẹ rồi. Nên anh khè ba cái ie tui chả quan tâm.
 
Last edited:
Nghe mấy lời complain là biết trình độ tới đâu rồi, còn đòi pull về hết cả server side rendering :sweat:
Trình độ có hạn thì chịu khó mà đặt câu hỏi thông minh 1 tí, kiểu như "Cách để update đống dependencies như nào cho hiệu quả'' để anh em còn góp ý, trình độ ko có vô nhận xét tùm lum rồi còn đòi chuyển hết mẹ về Serverside rendering cho ít bug, bó tay :go:

via theNEXTvoz for iPhone
 
Đọc qua thì thấy:
  • Làm việc ko có review code cẩn thận, chơi yolo cài yolo nên ỉa
  • Ko có viết tests, cho nên upgrade là ỉa
    • Cũng khá rảnh, upgrade liên tục dù ko có security concerns
  • Khổ dâm, đang webapp về lại webpage, mất đi tính flexible
  • Sau này lại fải maintain rồi ỉa tiếp
    • Chưa tính đến learning curve, inhouse thì curve nó càng lớn hơn
  • Ko biết xài "npm ci"
  • ...
Từ đầu topic tới giờ ko reply 1 cái gì, khả năng là bail để tăng tương tác forum
zFNuZTA.png
 
Back
Top