Missing Bower Assets

[deckar01]

Description

When upgrading from 1.7.5 to 1.8.1, the asset path provided in the bower config no longer exists.

Steps to Reproduce

1. Run bower install js-beautify
2. Include bower_components/js-beautify//js/lib/beautify.js in an HTML document

Environment

OS: Ubuntu 18.04 (64 bit)

Notes

There don't seem to be any bundled javascript assets in the bower package.

[bitwiseman]

Are bower packages created from github?

[deckar01]

Bower automatically pulls the git tags from the hosted git server that the package was registered with.

https://bower.io/docs/creating-packages/#register

[deckar01]

v1.7.5 had the build output checked into the repo, which is not considered best practice and likely why it was removed. Since bower doesn't have a pre-publish hook like npm, the build has to be ran post-install, which is discouraged by their documentation and is historically brittle.

bower/bower#249

The solution is probably to drop support for bower since it is deprecated.

we started recommending Yarn as an alternative to Bower for new front-end projects.

https://bower.io/blog/2017/how-to-migrate-away-from-bower/

The cleanest way to do that would be to check the assets into the repo one last time, publish a patch release, then follow the rest of the "How to Drop Bower Support" guide and remove the generated assets in a major release.

1. Before, notify all users of your module who might be affected by this change (see below)
2. Remove all distribution files and bower.json from repository
3. Tag repository with new major semver version (e.g from 3.5.6 to 4.0.0)
4. Don’t remove your component from Bower registry (via bower unregister)

https://bower.io/blog/2017/how-to-drop-bower-support/

[bitwiseman]

@deckar01 Thanks for the detailed info.
I've created a v1.8.2 tag that points to the gh-pages branch which includes the built files. Your immediate problem should be fixed.

The right fix for this is probably to use a release branch and do tags (and checked in generated files) on that branch. (As advised here: https://blog.kentcdodds.com/why-i-don-t-commit-generated-files-to-master-a4d76382564)

[deckar01]

Thanks for working on this. Maintaining bower support is a nice option also. 😄

[bitwiseman]

@deckar01 I don't know about maintain it in the long run, but not breaking it in the short-term is worth doing. And we're not ready to go to v2 yet so that's how it goes.

[deckar01]

I had a discussion about hesitation to release major versions in another project yesterday.

I am personally not a fan of building up breaking changes in a major version milestone. I think this pattern is an artifact of commercial software development with scheduled release windows. Without a hard release schedule, there is no mechanism for punting the backlog to the next major version.

Semver + upgrade guides should provide the assurance developers need to handle major releases dropping any time an improvement is backwards incompatible.

marshmallow-code/marshmallow#928 (comment)

[bitwiseman]

@deckar01 That is an interesting point. We've been avoiding 2.0 for some time, but maybe we don't need to.