Resolving location of assets.

[SamMousa]

When creating a library that depends on external assets what is the "recommended" way of doing things?

• Should I require the plugin? (I don't think most projects do this, like Yii2, but instead they document that it should be installed globally)
• Should I read the root composer.json file to find out where the assets are located?

Ideally the plugin would provide a method that resolves the asset path, since the plugin can always be loaded using the class loader. But if the plugin is installed globally it won't be available inside the project. Alternatively a lightweight composer package could be created that always gets installed by the plugin and has the same resolving logic as the globally installed package.

So maybe the solution is to:

1. Create a new composer package that just resolves the asset path(s).
2. Install that package automatically when any bower-asset or npm-asset is required.

For the resolving package I think having a static helper function is simplest:
Fxp\Composer\AssetPlugin::getNodeAssetPath() would work fine for most cases.
Optionally take an argument like the package name and resolve that to the directory for that specific package.

Ideally if the main project uses some kind of asset manager then it should be possible for the main project to set the base URL for the assets so the library can skip any asset publishing and use the base URL instead. By calling getNodeAssetUrl() for example.

I'd be up for creating such a lightweight composer package but I'm not sure this is the best approach or if other approaches exist.

[francoispluchino]

Unfortunately, you must stated in the documentation to install the plugin in mode global (see #7).

Regarding the resolution of assets, I have already develop this feature:

• the library fxp/require-asset
• the bundle for Symfony2/3 fxp/require-asset-bundle

The library using Assetic and including many helpers for Twig.

[SamMousa]

For me it's unclear how fxp/require-asset actually assists in finding the asset directory; in the docs I see stuff like this:

$configPackage = new ConfigPackage('foo_bar', __DIR__ . '/vendor/assets/foobar');

Which basically means I still have to know..

[francoispluchino]

It's the bundle that generate automatically the config (see the compiler pass and particularly ComposerAssetsPass).

I have not developed this feature for the library because it is already present for Symfony. But you can do a PR for that.

[SamMousa]

Ah okay, so basically the installed.json file in the composer directory contains all we need.
So the next question becomes how to detect composer installation directory..

And your bundle does this via the container:

->scalarNode('composer_installed_path')
                    ->defaultValue($this->rootDir.'/../vendor/composer/installed.json')
                    ->end()

Would it not be better to just use the autoloader class as an "anchor"?

dirname((new \ReflectionClass(\Composer\Autoload\ClassLoader::class))->getFileName())

That will always work regardless of "parent" framework. And then we could use that to get installed.json and get the *-asset-library packages and their paths.

This would also remove the need for custom configuration when using a non-standard composer path!

[francoispluchino]

Yes, we can use the reflection of ClassLoader, and move the findAssetPackages in library (to static util class?).

[SamMousa]

Yes, that would be great for non-symfony users :)
-- Just did a test regarding parse times of installed.json:
Real installed.json file for a yii2 project, size about 160KB, running on core i2500k inside a homestead vm, got the following results doing 20 iterations of 1000 loads:

Average 1000x: 1.6277709126472
Max 1000x: 1.7626240253448
Min 1000x: 1.5363171100616

So basically this would add about 2ms to page load times.

[francoispluchino]

I think I will create an independent library for resolving the paths and which can be integrated in any project.

[SamMousa]

Okay great, I don't think it needs to be much of a library though ^^

Probably something like the PackageUtils class: https://github.com/francoispluchino/fxp-require-asset/blob/master/Assetic/Util/PackageUtils.php

Anyway, thanks for the prompt responses! Let me know if you need more input.

[francoispluchino]

It's not possible, because the class will not be loaded by the Classloader (plugin installed in global mode:) ).

[SamMousa]

I don't mean it must be that exact class, just something like that; simple static class with a few static functions.

[SamMousa]

I think I will create an independent library for resolving the paths and which can be integrated in any project.

Will you still do that?

[francoispluchino]

Considering the last comments, is it really useful?

[SamMousa]

The comments refer to the global installation, but if there is a separate small footprint library that allows for resolution of asset paths then that library could be included in project-specific composer.json right?