3 ms·
The use case I've seen is for iteratively moving away from a legacy system. Say you have monolithic front end and you want to move to a new framework/version/e
by smessina 6y ago
The use case I've seen is for iteratively moving away from a legacy system.
Say you have monolithic front end and you want to move to a new framework/version/etc. Instead of rewriting the whole app, you can approach it feature-by-feature and slowly replace the legacy app, Ship of Theseus style[0].
[0]: https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus
- throwaway888abc 6y agoThank you
- adamredwoods 6y agoThis is exactly what we're doing now. Some of the problems we've seen thus far is how to maintain packages but allow for high-iteration development. It is cumbersome using a packaging service, so at best it's being able to decide what to keep in a shared rep, versus things that are being rapidly developed in it's own rep. Any component that needs specific tweak then becomes duplicated and sadly, code-reuse and maintainability suffers. Another problem is tracking down inter-component bugs, especially if the code is behind a repository. How am I to make small tweaks? Bleh! I haven't digested what Webpack 5 is doing, but I'm skeptical, mostly because I don't like Webpack's plugin implementation.