Unable to find file "@AvanzuAdminThemeBundle/Resources/public/vendor/fullcalendar/dist/fullcalendar.min.js"

[xmontero]

I have not changed anything in my config and suddently installing, it says:

[InvalidArgumentException]
Unable to find file "@AvanzuAdminThemeBundle/Resources/public/vendor/fullcalendar/dist/fullcalendar.min.js".

March 12th, I deployed and it installed perfectly. I just do a deploy today and it breaks.

It's a recurrent problem with this bundle that it just "breaks" from time to time probably because a lack of "locking" the versions.

the required version in my composer.json is

"avanzu/admin-theme-bundle": "^1.3.12",

In the lock, I see this:

"version": "1.3.x-dev",

Log

php bin/console avanzu:admin:build-assets --env=prod
22:28:34 ERROR     [console] Error thrown while running command "avanzu:admin:build-assets --env=prod". Message: "Unable to find file "@AvanzuAdminThemeBundle/Resources/public/vendor/fullcalendar/dist/fullcalendar.min.js"." ["error" => InvalidArgumentException { …},"command" => "avanzu:admin:build-assets --env=prod","message" => "Unable to find file "@AvanzuAdminThemeBundle/Resources/public/vendor/fullcalendar/dist/fullcalendar.min.js"."] []

  [InvalidArgumentException]
  Unable to find file "@AvanzuAdminThemeBundle/Resources/public/vendor/fullcalendar/dist/fullcalendar.min.js".

avanzu:admin:build-assets [-c|--compress] [-m|--mangle] [--uglifyjs-bin [UGLIFYJS-BIN]] [--uglifycss-bin [UGLIFYCSS-BIN]] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command>

Debug info

Component	Version
Symfony version	Symfony 3.3.10
AdminThemeBundle	^1.3.12 (composer.json), 1.3.x-dev (composer.lock)
Operating System	Linux xxxx 4.4.0-89-generic #112-Ubuntu SMP Mon Jul 31 19:38:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[xmontero]

The problem is a major-bump change in the versioning of fullcalendar.

in my-nice-project/vendor/avanzu/admin-theme-bundle/Resources/public/vendor/fullcalendar/CHANGELOG.md I can see that the properly working version starts with this:

v3.10.0 (2019-01-10)

while the failing installation downloaded a version whose CHANGELOG.md starts with:

v4.0.1 (2019-03-18)

which is coherent on "failing today" as this change is super-recent.

So we need to lock-down the installed version to 3.10.0 to ensure that things do not randomly break.

Should'nt we have to lock ALL the downloaded packages? It is a pitty that this amazing AdminThemeBundle is failing every each other week because the installation is not deterministic.

If we correct package by package as they break we will not be preveting this to happen again: If package A fails and we correct it, okey, package A won't fail agail but it'll probably fail package B.

We should find a way to ensure that installation is always sure. Otherwise it completely destroys the confidence in the next deploy even if you just changed a single line in your code. I've even thoght in abandoning the usage of this bundle just for this reason and I'm preventing to recommend it for new projects specifically because of this lack of confidence.

Who should decide on this? If anyone does the effort of locking it all, will a pull-request be merged or discarded?

[shakaran]

@xmontero thanks for your report. Unfortunally the old 1.3.x series has in bower.json a lot versions with "*" and with the time it gets rusty. In new series releases it will be more adjusted for avoid BC. Closing as fixed with 1.3.13. Feel free to make a PR against 1.3.x branch if you know every locking dependency stable

[xmontero]

I'm going to test now, but taking advantage we are on this, and both online, I'll try to discover also the proper version for bootbox. I had to tune my deployer to make symlinks to make it work also due to versioning...

[xmontero]

Ah well... taking this "Feel free to make a PR against 1.3.x branch if you know every locking dependency stable" invitation, I'll do it tomorrow (2am here in Spain and tomorrow I'll have to be at a client's office soon).

Thanks for the current correction. I'll try to lock all them and do a PR. Thanks for that.

[xmontero]

• PR at #252 and tested locally that it perfectly installs.
• To do so, I've done an installation from the v1.3.13 and checked all the versions that were installed.
• Then I replaced all the versions to te specific numbers. Even for those that previously they were'nt * but ranges, I opted to lock them down to specific patch version so in theory the risk of breaking an installation is nearly zero.
• The only risk is if any of the locked versions in turn depend on other packages and also they did their dependencies badly. We'll assume this does not happen or if so, there are large communities there taking care of all those javascript packages, we'll care only of our loved Avanzu bundle.
• I also locked down the AdminLte itself to a concrete version. This is on purpose.

From now on, (if merged) this 1.3.x branch will always have to update those files if the main developers require a specific new feature released in future versions.