chore: subsplit wip — Enzo will have to change this title :) #1908
Conversation
|
Still need to fix the tests, also discovered a bug in the container that I fixed |
| // Remote branch does not exist yet | ||
| } | ||
|
|
||
| // Don't we have a recursive directory copy function somewhere?? |
There was a problem hiding this comment.
We do now: #1909
However, this is not the right approach. We need to use actual git subtree split (or an equivalent alternative) to keep the history and tags in sync with the main monorepo.
There was a problem hiding this comment.
to keep the history and tags in sync with the main monorepo
Ah, I was under the impression the release script took care of keeping tags in sync, actually, but that was probably a wrong assumption
When it comes to history: I really don't care about keeping it in sync. However, tags are important indeed.
There was a problem hiding this comment.
You need to care about history. This will break Packagist if you don't.
| }, | ||
| "autoload-dev": { | ||
| "psr-4": { | ||
| "App\\": "app/", |
There was a problem hiding this comment.
We definitely need to use another directory than app 😬
Something like steward/, release/, cd/, or something more specific like that.
There was a problem hiding this comment.
Agree, I used app as a placeholder. Any preferences?
There was a problem hiding this comment.
This needs to be a separate entry point, to not be confused with what's strictly related to testing the framework itself
There was a problem hiding this comment.
TBH I never use ./tempest anymore for testing, that's a remnant from way back in the day. If I need to test the framework with real apps, I have a separate project for that where I symlink tempest/framework.
So I'm fine for removing all the testing stuff, and only keep one binary for these kinds of tasks.
I don't have a strong opinion on whether the binary itself should be renamed, but it would be a minor inconvenience for me if it did
There was a problem hiding this comment.
So I'm fine for removing all the testing stuff, and only keep one binary for these kinds of tasks.
That'd be great—I was never really a fan of all the test-time discovery and this binary
I don't have a strong opinion on whether the binary itself should be renamed
I would be fine not renaming it if we ended up cleaning up all the stuff around it
No description provided.