Are the generated files supposed to be gitignored?

[kirtangajjar]

Question:

Are the files that are generated by this package supposed to be gitignored? or is it better to commit them to the repo?

[uuf6429]

That's really up to you (or your team).

Here are a few points to consider:

• If the generated files are not always up to date, you might end up in an inconsistent state - in which case it's probably better to have an "all or nothing" approach (and therefore would be better to not commit these files)
• If you're using code-analysis tools, it might be better to have these files instead of a tonne of warnings about missing methods and so on
  • But one could also argue that you can generate these files before analysis
• Some devs might argue that these files are not part of the project in the sense that the projects runs fine without them
• The PhpStorm metadata file is specific to the IDE, so again: not useful to other IDEs, not part of the project

PS: I'm not a contributor to this project, just happened to see this question.

[mfn]

There used to be some issues making the generated file(s) not so useable because they were not reproducible (e.g. they contained timestamp or missed a sort somewhere and then randomly things changed), but I think today it's "mostly fine".

I also agree with @uuf6429 , I think it's a "your decision to make" thing.

In my commercial projects they are ignored, but thinking about it again, maybe it would be nice to have them there coupled with CI to make sure they're up2date, but haven't given it much more thought beyond that.

[FunctionDJ]

If you have the option to generate them with your CI/CD pipeline for example when running code analysis remotely, then don't commit these.

The information contained is supposed to be reproducable from all the other files you commit (your normal code).

Committing what is essentially a "build artifact" just adds the possibility of your normal source code and the helper files getting out of sync and causing trouble.

That's my personal take on it.

[mfn]

Committing what is essentially a "build artifact" just adds the possibility of your normal source code and the helper files getting out of sync and causing trouble.

Are you sure?

The were fact when ide-helper would run in CI and a commit would be possible (i.e. because the ide helper files changed) is an indicator it's not in sync?

But, I may have easily missed the obvious part here 🤷‍♀️

[FunctionDJ]

I don't know what you mean, but if i write a macro right now, commit, and push, then we already have "conflicting" information in the repository. If all the CI/CD and tooling is properly set up to regenerate these files, then it's not a big deal, but then why version control these files in the first place?

[mfn]

but then why version control these files in the first place?

So every dev on the eam immediately benefits from them and not having to think to run the ide-helper themselves.

[uuf6429]

but then why version control these files in the first place?

So every dev on the eam immediately benefits from them and not having to think to run the ide-helper themselves.

I have to disagree - since the tool solves different problems (=many reasons that require a rerun), it's probably better that the team gets used to running it.

[FunctionDJ]

but then why version control these files in the first place?

So every dev on the eam immediately benefits from them and not having to think to run the ide-helper themselves.

There's only a benefit if it's always up-to-date. So, logically, you shouldn't rely on someone else keeping the files up-to-date, and generate them on your in every repository instance, for example using Git hooks if you want automation. Then the files always get generated from the code you check out, and you don't need to trust someone else to maintain the files.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this issue is still present on the latest version of this library on supported Laravel versions, please let us know by replying to this issue so we can investigate further. Thank you for your contribution! Apologies for any delayed response on our side.

[olexoliinyk0]

for example using Git hooks if you want automation

Hi, @FunctionDJ! You mentioned back there that there could be a way to add ide-helper run to git hooks. I'm trying to do this only for models by checking in pre-commit that git has certain files in diff and then running ide-helper:models like this:

IDE_HELPER_FOR_MODELS=$(git diff --staged --name-only --diff-filter=d $against | grep -E 'app/(Models|Traits)/|database/migrations/' | wc -l)

if [ "$IDE_HELPER_FOR_MODELS" != "0" ]; then
    php artisan ide-helper:models --write
    echo "-- INFO: ide-helper:models was run and exited with code $?"
    exit 1
fi

The problem is that it will run on every next attempt to commit, not letting you complete the commit.

The idea is to have that run only once and let the committer know that it was run to add modified (if any) files to the staged changes.

I know there's a post_migrate config option available, but it runs only one Artisan command and does so on every migrate, which can be annoying when you switch between branches often (and does not take into account changes within Models or Traits).

Thanks in advance for any response!

[FunctionDJ]

@olexoliinyk0 looks like you want to version control these files. my idea with hooks was that you don't check these files into git and instead use hooks to automatically generate/update them on checkouts.

[olexoliinyk0]

version control these files

Yes, I do use --write frag, which adds annotations to the original Models' files, and everything goes to git.

Your idea is valid, thanks! For now, I've settled with using post-commit and "WARNING: you've changed some files that can affect phpDoc of the Models" message. Unfortunately, VSCode does not take post-commit exit 1 code into account and does not show the message, but the initial idea of moving it there was to see that message as a notification at least (running it silently is not an option).