search

Hypercosm / HIDL

Hypercosm Interface Description Language
https://hypercosm.dev/HIDL
0 stars 0 forks source link

Doesnt remove files that would no longer be generated #18

Open aDotInTheVoid opened 2 years ago

aDotInTheVoid commented 2 years ago

Say you add a new extension, a markdown file will be created with its contents.

But when you remove it from HIDL, the md is still there

daeken commented 2 years ago

I'm torn on this. On one hand, deleting the contents of the destination directory (at least *.md) would be a clean solution. On the other hand, I really don't want to nuke the wrong thing by accident.

Maybe instead of committing the docs ourselves, we could have a post-commit hook that generates the json and docs?

aDotInTheVoid commented 2 years ago

On the other hand, I really don't want to nuke the wrong thing by accident.

What if we error if their exist files in a folder that only contains autogened, and it wasnt autogened, we error, but it needs to be manually removed.

daeken commented 2 years ago

I think that approach is fine and keeps us safe, but is there any reason not to automate rebuilding it each push? Feels like a relatively easy win.

aDotInTheVoid commented 2 years ago

Eventullay, we probably will, but for now I like the commit that changes how the output is created being the same as the one that changes the output.

Once we move from mainly iterating on the tooling, to iterating on the content, that seems worthwhile

daeken commented 2 years ago

SGTM. I think your approach above is a good one.

nicolas17 commented 2 years ago

for now I like the commit that changes how the output is created being the same as the one that changes the output

I agree. I think it's good to have an automated job that rebuilds on each push, and makes a push of its own if the generated files changed. But from experience in another repo, it's also good to build it and push it yourself when you change the sources, for example so that git log / git blame on the generated files points at your commits (with a sane commit message etc).

If you forget, or you push outdated generated files, or your local generation went wrong somehow, the automated job will fix it. But in general it shouldn't need to.

daeken commented 2 years ago

it's also good to build it and push it yourself when you change the sources, for example so that git log / git blame on the generated files points at your commits (with a sane commit message etc).

Can this be solved with a precommit hook that does the build? I can't remember how much you can actually bake into that.