Updating BLT with composer

[dpagini]

This is more of a question for the maintainers rather than an explicit issue, but I wasn't sure the best approach to ask these questions....

In a project that relies on BLT, running $ composer update leaves me with several files that BLT wants to update. I have struggled with the idea of ignoring the BLT updates, or just leaving these files alone and moving my changes/extensions from BLT managed files to a new file. I want to ask about two examples, and see if there is a recommended approach to fixing this.

First example - the factory-hooks/pre-settings-php/includes.php file. I am following the BLT approach of splitting functional settings changes out into their own files. Because of this, I have a bunch of settings files to also include in the site factory settings file. My approach, until now, has been to add an additional line to this file to include my project specific settings. Everytime I run the update though, BLT wants to delete my custom additions to this file when it overwrites the file from its template/ directory.
I think I see 3 options here...

1. Continue what I'm doing. When running $ composer update, just discard the BLT changes.
2. Add a new file, maybe factory-hooks/pre-settings-php/my.includes.php which includes my custom files. In this case, it seems silly to have the original file under source control, and maybe it should be a build artifact only? or .gitignored?
3. I think I saw one of the newest options in BLT was the ability to include an "ignore" file to tell BLT to leave my local files alone. Would this be the best solution?

Second example - my project.yml file gets the lightning target-hooks re-enabled on every update. Since my project does not rely on lightning, we comment out these lines. BLT wants to re-enable them every time I update. I think "option" 1 and 3 from my first example are my best paths forward here, right? I am hesitant to go with option 3, because then I may miss upstream updates that way, and option 1 at least gives some visibility into a new change. Thoughts?

Bonus - another file that gives me a problem is tests/behat/features/bootstrap/Drupal/FeatureContext.php which is where our custom behat code was added. I think I might have to "extend" this blank file/class, but why have a blank file unless you want to suggest to users to use it...? Maybe this file should only be copied from the template folder on the "create project" command, and not the "update" commands?

Sorry if I don't have suggested fixes here, I just wanted to ask what the expected use of the framework would be in these scenarios. If there is maybe an issue here, and there's anything I can do to help document or test a fix for, please let me know.... and as always, thanks for your hard work on this project!

[grasmash]

Option 3 is the way to go for all but project.yml.

For any files that are getting clobbered, add an entry to https://github.com/acquia/blt/blob/8.x/scripts/blt/ignore-existing.txt.

I'd be happy to update the list upstream.

As for project.yml, we should probably add lighting hooks only if lighting is the specified profile.

[dpagini]

Thanks for the quick reply. I feel like at some point I'm going to run into the scenario where I miss an upstream change, but at least this method should reduce the amount of time a BLT update would take to sort through.
For the behat tests, I'm just not experienced enough with those... would the expectation be that custom code would go into that FeatureContext.php file? Or should there be another place to put custom code that behat will use?

[grasmash]

Yes custom code should go into FeatureContext.php, so it should not be overwritten.

As for project.yml, you should define your own target-hooks. They will not be overwritten if they already exist. It's ok if they don't actually do anything. They can just echo "nothing to see here" or exit 0