NEW Allow files to have a .tmpl extension which is stripped

[dhensby]

Allows a fix for silverstripe/recipe-cms#9

--

Added:

• Tests, travis integration, test namespaces and autoloading
• Added APIs to better facilitate mocking (such as file_exists, file_get_contents, copy, etc)
• Support for recipe files to end in .tmpl so that they don't get picked up by IDEs as first class classes

[tractorcow]

@dhensby good idea but it won't work if you composer create-project silverstripe/recipe-cms. Can you make sure it renames base files as well in the postCreate hook?

[tractorcow]

As commented; Make sure it renames in post-create-project.

[dhensby]

@tractorcow this appeared to be the canonical source of mapping from the composer meta data to the filename and I couldn't (and can't now) find anywhere referencing postCreate hooks / logic.

Any pointers where to look for that?

[tractorcow]

Check out this bit of code:

public static function getSubscribedEvents()
    {
        return [
            'post-create-project-cmd' => 'cleanupProject',
            'post-package-update' => 'installPackage',
            'post-package-install' => 'installPackage',
        ];
    }

You would want to add your hook in the cleanupProject hook. Unfortunately you may need to do a bit of refactoring in RecipeInstaller; I suggest a new method designed for renaming root files in the base recipe.

The logic for this method would look VERY similar to RecipeInstaller::installProjectFiles(), except instead of installing files it'll just rename root project files.

Let me know if you need any more help. ;P

[tractorcow]

Did you mean substr($destination, 0, -5)? $destination would end up just being .tmpl.

[dhensby]

whoops - fixed

[tractorcow]

This check

// Add file to installed (even if already exists)
            if (!in_array($relativePath, $installedFiles)) {

Should we loosen this check so that it matches path with / without the tml suffix? Just to ensure backwards compatibility. Otherwise files that were deleted will be re-created once and you'll end up with duplicate ["Page.php", "Page.php.tmpl"] in the list.

[dhensby]

@tractorcow cleanupProject doesn't appear to inspect the values of files that are defined in extra meta data. it just unsets the values... I'm not sure how the .tmpl logic would fit in here? sorry if I'm being dense.

recipe-plugin/src/RecipePlugin.php

Lines 89 to 110 in 3e16a5b

	/**
	* Cleanup the root package on create-project
	*
	* @param Event $event
	*/
	public function cleanupProject(Event $event)
	{
	$file = new JsonFile(Factory::getComposerFile());
	$data = $file->read();
	// Remove project and public files from project
	unset($data['extra'][self::PROJECT_FILES]);
	unset($data['extra'][self::PUBLIC_FILES]);
	// Remove redundant empty extra
	if (empty($data['extra'])) {
	unset($data['extra']);
	}
	// Save back to composer.json
	$file->write($data);
	}

[dhensby]

Should we loosen this check so that it matches path with / without the tml suffix? Just to ensure backwards compatibility

This is currently the case. We normalise the .tmpl path early so that comparisons are done as if it was always named without it. Thus it's written to the composer.json without the .tmpl (if it had one) and compared without it too, I've added a test case to cover this under testInstallProjectFilesWithoutTmplExtension

[tractorcow]

@tractorcow cleanupProject doesn't appear to inspect the values of files that are defined in extra meta data. it just unsets the values... I'm not sure how the .tmpl logic would fit in here? sorry if I'm being dense.

You do it before clearing them. The logic is:

• Install project
  • Install each library in project
    • plugin installs files for each library, renaming .tmpl as it goes
• read composer.json in cleanupProject:
  • For each extra, rename .tmpl (in place)
  • then unset it from extra (since they aren't used anymore after initial install)

We normalise the .tmpl path early

Good call just making sure. :)

[tractorcow]

Do you need this condition twice? They both compare the same string that comes from $path? It's hard to follow.
$path -> $destination -> check ext
$path -> $relativePath -> check ext

[maxime-rainville]

Is this still blocked? Looks like all of @tractorcow feedback has been addressed?

[dhensby]

Is this still blocked? Looks like all of @tractorcow feedback has been addressed?

it just doesn't work. I think it's actually really difficult to do :/

[maxime-rainville]

😞 Shall we close the PR then? Doesn't look like it's going to be addressed in the near future.

[dhensby]

Yeah - I think I got as far as I could and wasn't getting anywhere when I last worked on it. It's a big shame, though, as it's a big pain when IDEs pick up these files :(