Add a bower package

[brianmhunt]

It would be very helpful to have a Bower package for installing PDF.js.

The steps for Bower registration are straightforward:

1. Create a bower.json to define the package, that would look something like this:

{
  "name": "PDF.js",
  "version": "0.8.477",
  "main": "./PDF.js",
  "ignore": [
    ".jshintrc",
    "**/*.txt"
  ],
  "dependencies": {
    "<name>": "<version>",
    "<name>": "<folder>",
    "<name>": "<package>"
  },
  "devDependencies": {
    "<test-framework-name>": "<version>"
  }
}

1. Register the package with

$ bower register <my-package-name> <git-endpoint>

Then eager users could install PDF.js with something like bower install PDF.js.

A couple caveats:

1. the Git tags should be kept up-to-date with the current version (i.e. tags must be pushed);
2. it would be most effective if a built version of PDF.js were deployed with each tag.

Cheers

[yurydelendik]

It would be very helpful to have a Bower package for installing PDF.js.

Why? How many PDF.js users will use this method?

[brianmhunt]

I can speak of only one potential person who would use this for sure 😄 but Bower is a very popular package manager for browser-js, so there are quite a number of potential users.

The github repository shows that bower has slightly more stars than PDF.js and nearly twice as many watchers.

There are alternative package managers as well, but bower has (in my limited experience) distinguished itself and is quite popular for good reason.

If support is put together for bower, likely the other package managers would be fairly straightforward too. (If they are not already supported). In other words it is a fairly transferable investment.

[yurydelendik]

This feature is out of scope of this project. It can be provided by the contributor who wishes to support Bower community. Closing as invalid for now.

[brianmhunt]

Thanks for reviewing. Hopefully someone savvy with PDF.js and Bower/etc can pick it up. Cheers.

[luizfilipe]

I think this could be awesome, I'm working on a project that we have to keep all dependecies installed in all developers environments, PDF.js is one of those dependencies, with bower we dont have to add all PDF.js API inside of our repo. Indeed, at the same time, we could track the needed files from the Mozilla repo with bower commands

[yurydelendik]

Hopefully someone savvy with PDF.js and Bower/etc can pick it up.

I think this could be awesome...

@luizfilipe oh, I agree :) I think the main problem is to find somebody who can take it and provide continued support for this feature. And this is not a technical problem -- that's why this issue is closed here (see https://github.com/mozilla/pdf.js/blob/master/CONTRIBUTING.md)

[luizfilipe]

@yurydelendik I can write a bower.json file and keep it if you agree. Also, it be a awesome cause I can seek for what is new to let bower JSON with the latest dependencies.

[yurydelendik]

I can write a bower.json file and keep it if you agree

Sorry, I'm not sure what does it mean. bower.json requires version to be specified and we assign version during build process (e.g. during node make generic). do you need to write something that will "build" this file automatically?

[luizfilipe]

Hmmm, Now I understand the need... I'll see the build script to try find a solution

[twse]

@luizfilipe He uses an accent as an apostrophe (example: “it´s” instead of “it's”) when trying to comment for problematic keyboard driver semantics. He has now edited the comments to replace the accents.

[joseym]

👍 Being able to get the necessary files with bower rather than having to build independently would be really useful.

Having to get the project, build, then copy production files into a project that needs them is often just an unnecessarily extra step. Bower is common place for frontend work these days. I think this issue should be re-opened.

[joseym]

Here's a 3rd party solution: https://github.com/joseym/pdfjs-bower

[Glavin001]

Being able to get the necessary files with bower rather than having to build independently would be really useful.

Having to get the project, build, then copy production files into a project that needs them is often just an unnecessary extra step. Bower is comment place for frontend work these days. I think this issue should be re-opened.

Absolutely agree!

Here's a 3rd party solution: https://github.com/joseym/pdfjs-bower

Thank you @joseym!

[joseym]

my pleasure. Working on adding minification into the build process.

[jbaris]

Thanks you @joseym!

[tmorrow-hyphensolutions]

@joseym , you have not included the viewer? This is why I need pdfjs, for the viewer. Thanks!
@yurydelendik, bower is "the way" developers bring packages into their applications. It's more popular than ever. Thanks!

I got the viewer from bower package "pdfjs-viewer" and learned how to load it from http://stackoverflow.com/a/28525093/1045881

[EvanCarroll]

There is a good argument that bower is on the way out.. @tmorrow-hyphensolutions. The ideas was essentially to have a different repo for frontend and backend code. Made sense at the time. However, that's a useful social distinction that needn't be technical. The technical reasons for it was that some people wanted to hack into window or use Require.js, and npm having originated as a node repository always requires CommonJS. This technical nugget was made obsolete with the UMD module pattern.

Now there is no reason for Bower technically, and socially the reason for it is a failure and even a technical impediment. If you have bower installing to a different directory and you decide to move to a build system like Broccoli/Gulp/Grunt, you have to configure them to work with the bower directory using some other kind of hack like debowerify. All of this is silly. Modern JS demands a build system and the migration will be common from <script> tags to pull in resources, to pulling in a built bundle.

So death to bower. I'll say it, many others have said it too. 1, 2.

In fact, you could argue the whole Yeoman workflow is totally dead and a thing of the past. Stay away from Yeoman, Bower, and Grunt.

As a follower of this bug for over a year, I support a Won't Fix on it.

[brianmhunt]

Thanks @EvanCarroll – As submitter of this issue, I do not disagree with your post i.e. I am fine if there is no bower package, on the condition that a client-side package is available on the key alternative: npm (and it looks like there is such a npm package – pdfjs-dist, but I have not yet checked it out).

[EvanCarroll]

Well, at that pdfjs-dist has a bower file so this should be closed.

However, the important issue here is the adoption of UMD because that makes bower irrelevant, and makes publication to npm universally acceptable. That's mentioned here but nothing is done in that direction.

[brianmhunt]

This issue was closed two years ago :)

[tmorrow-hyphensolutions]

@EvanCarroll , I'm looking forward to UMD. In the meantime, Visual Studio does not look like it supports it. They support bower and npm in the 2015 IDE. Perhaps they are behind the times :)

[EvanCarroll]

Bower and Npm are package.json and bower.json files respectively. UMD is an idiom which you use to create your module, like Require.js, and CommonJS. You can find it here. Just start off your module with that and you've got UMD.

[mbtakanov]

The issue was closed when bower was not that popular at the time. But look at us now. Everyone is on bower and we can laugh on comments like "Who will ever use XXX from bower?". It would be awesome if you support it officially. Thanks.

[Snuffleupagus]

It would be awesome if you support it officially. Thanks.

It's already supported, and has been for quite some time, please refer to https://github.com/mozilla/pdf.js#using-pdfjs-in-a-web-application.
Note how the first search result on https://bower.io/search/?q=pdfjs links to https://github.com/mozilla/pdfjs-dist.