Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
xmontero opened this issue Mar 18, 2019 · 5 comments

Comments

@xmontero
Copy link

commented Mar 18, 2019

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

This comment has been minimized.

Copy link
Author

commented Mar 19, 2019

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 added a commit that referenced this issue Mar 19, 2019

@shakaran shakaran self-assigned this Mar 19, 2019

@shakaran shakaran added the 4 - Done label Mar 19, 2019

@shakaran shakaran added this to the Old 1.3.x versions milestone Mar 19, 2019

@shakaran shakaran added the bug label Mar 19, 2019

@shakaran

This comment has been minimized.

Copy link
Collaborator

commented Mar 19, 2019

@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

@shakaran shakaran closed this Mar 19, 2019

@xmontero

This comment has been minimized.

Copy link
Author

commented Mar 19, 2019

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

This comment has been minimized.

Copy link
Author

commented Mar 19, 2019

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 added a commit to xmontero/AdminThemeBundle that referenced this issue Mar 19, 2019

Locks all versions down to specific numbers (to the patch level) remo…
…ving any randomness in installations. Relates to issue avanzu#251
@xmontero

This comment has been minimized.

Copy link
Author

commented Mar 20, 2019

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.