Marco "Ocramius" Pivetta

I think I distilled the "splitting internal code into packages" problem.

The simplest way to put it is that atomic change/refactoring is no longer possible.

Split your internal code into packages managed by a package manager => you added hours of work for the team for each change, long-term.

Mar 27, 2023 at 10:08amWeb
Show threadhttoMar 27, 2023
@ocramius OK, curious question. Assuming putting everything or almost everything of your codebase into one monolith. Any good advice on how to run tests/inspection/whatever checks against the actual changes and not against an evergrowing pile of whatever one may call it?
Show threadThomasToSpaceMar 27, 2023
@htto @ocramius You can run only certain pipelines based on what files are changed. Works quite well for the backend+frontend apps we've had at my old job.
Show threadMarco "Ocramius" PivettaMar 27, 2023

@thomastospace @htto this.

Also, consider using tools like buildx, nix, etc. to determine which parts need re-testing: they automatically invalidate any results depending on inputs (and changes thereof)

Show threadhttoMar 27, 2023

@ocramius @thomastospace While I do grok the detection of a class change to run it's direct tests. Do these approaches cope well with changes in base/utility/dependency/whatever classes to make sure their users don't fall apart? Or am I way too off and that is out of scope?

Also, my admin would probably nix me for coming up with something shiny and unfamiliar as nix 🫠

Show threadMarco "Ocramius" PivettaMar 27, 2023

@htto @thomastospace certainly worth exploring new tooling: assuming you have a directed dependency graph, you get good/consistent results.

Anyway, it was just a suggestion: limiting CI pipelines to certain changes/directories also works.

Parallelizing is currently the best approach, IMO (skipping stuff is always risky)

Show threadMartin HerndlMar 27, 2023
@ocramius hey, it works fine. I just have to make sure to follow semver and kind of pretend that the internal packages are big OSS packages used by many people. But they're actually only used in another internal app 😅 😢
Show threadKevin Boyd (he/him) 🇨🇦Mar 27, 2023
@ocramius sometimes, yes. Other times, such as when there are two global products sharing the code (and possibly more on the way), the changes do benefit from being coordinated and versioned that way.
Show threadAlessandro LaiMar 28, 2023
@kboyd @ocramius that sounds like an undiscovered domain/service to me...