Bower support and dist/* files

[schmunk42]

Would it be possible to re-add bower.json?

Removed here: c631874

It breaks several things, like:
2amigos/yii2-chartjs-widget#18
fxpio/composer-asset-plugin#242
bedezign/yii2-audit#159

[panzarino]

You can still install with bower through the bower-npm-resolver as explained in the installation portion of the docs.

[etimberg]

Further, with the build system changes this cannot be installed via bower because the release source code zip doesn't contain the built files

[schmunk42]

We're installing the plugin via https://github.com/fxpio/composer-asset-plugin - so I don't think npm-bower-resolver would work here. Probably the best option for the widget is to switch to npm.

Just to be curios, what was the reason behind dropping bower-support, like maintaining two package managers or did bower just not work fine?

[fabianTMC]

I am curious as well as to why bower support was dropped.

[madmoizo]

Indeed, dist folder was useful for dependencies management, angular wrappers or whatever

[panzarino]

You can get the dist folder through building with gulp build.

[koxon]

Could you gulp build for us?

This adds another step to the deployment process. And I'm not planning to add gulp just for one dependency.

[miguelmich]

There is a way to include the dist folder only on releases even if this folder is ignored by default, this way it will be available when checkout releases tags, popular repos like jQuery or full calendar manage distribution on releases like this.

I guess you are currently manually adding the compiled files on each release. However you could add this behavior automatically in your release task in gulp, this way everybody will be happy and no dist folder will be in source control, only on releases :)

What do you think?

[etimberg]

@miguelmich the release already happens automatically. @simonbrunel set it up so that it adds the built files once the build finishes. As far as I know, there is no way to have those files inside the source zip (which is what bower uses) without checking those files in.

[simonbrunel]

@schmunk42 @fabianTMC: main reasons why we removed dist files (and thus bower support):

• not obvious which version was compiled (in master/branches)
• confusing because these files were not always up to date with latest sources
• pollutes commit history and PR since many people were committing their own built files in PR
• makes more complicated manipulating git history for developers, such as rebasing

@koxon: we already build them for you, no need to deal with gulp or even npm. You can get it from the Git release page or the CDN (or the npm package if you use npm). We provide many formats, see #2555 for details.

@miguelmich: the only manual process is the Git tag creation, everything else is automated: build, git release (attached files), NPM release and deployment to the CDN (described in #2555). But I see what you mean with jQuery, they have the Git tag automatically created and in the same time they push dist files only for the tag. So finally, dist files are never on master/branches, neither PRs. Could be something interesting to investigate :)

I don't know bower enough, but I'm sure there are different ways to grab libraries from URL (Git release downloads or CDN) without relying on Git repository, right?

[miguelmich]

Hello @etimberg @simonbrunel,

Ok, now I understand better your workflow, however one of the main concerns about using direct urls is that we can't manage version tags.

It is also possible to include the dist folder only in the releases tags and master branch will be clean always for PRs like mentioned here: (fullcalendar/fullcalendar#2989 (comment))

This could be an addition to the current build process instead of some kind refactor, If you want I can make a research more deeply about this and give you a better idea of how it could work.

Thanks

[miguelmich]

Hello guys,

I want to share what I found so far; The behavior mentioned above is possible to achieve following these steps in the release task:

• Run build task
• Checkout a detached state
• Add dist folder files to commit
• Commit these files
• Create a tag
• Push tag to origin
• Reset the detached state
• Checkout HEAD

This process is explained in more detail here, and these two repos are using the same releasing workflow as you can see in their release tasks:
https://github.com/fullcalendar/fullcalendar/blob/master/build/build-release.sh
https://github.com/melonjs/melonJS/blob/master/tasks/release.js

Both are using a symbolic reference pointing to HEAD (git symbolic-ref HEAD) in order to return to the previous branch prior to the detached state.

[simonbrunel]

Thanks @miguelmich, will look it more closely, however our current build/release process is triggered from the git tag creation, so this solution doesn't seem to work out of the box and would require other major changes in our workflow.

The first link you posted is from 2014, but since there are alternatives, such as bower-npm-resolver. So I wondering why this solution is not suitable?