Package.json as replacement for bower.json and .bowerrc

[zanona]

I am using bower for a while now and was analysing that, at the same time I am using bower I am also required to add files to my project which don't really seem necessary. IMHO bower.json and .bowerrc are two of them.

Isn't it possible for bower to simply use an attribute inside package.json file named bower?
Take volo, for example, the great thing about it is that it is invisible. All declarations are made inside package.json file itself and it also re-uses common fields like name, author, version, etc.

package.json

{
    "name": "my-widget", // common between node and bower
    "version": "0.0.1", // commom field
    "description": "My Awesome Widget", // commom field
    "scripts": { ... }, //node related
    "dependencies": {...}, //node related
    "bower": {
         "directory": "src/components", // .bowerrc statements
         "version": "0.0.2", // overwrides root attribute if present
         "dependencies": { … }
    }
}

This way, instead of having an structure like this:

.
├── .bowerrc
├── bower.json
├── node_modules
├── package.json
└── src
    └── components

We would have this knowing package.json is the central point of attention for both node, bower (and any other package manager) making it clear that this doesn't needs to be related to node development at all in case it's not needed. It would be perfectly valid only for bower packages as well.

.
├── node_modules
├── package.json
└── src
    └── components

I believe this really makes a whole difference on the perception of complexity behind your code, it just simplifies it gracefully.

It would be great to know what do you guys think.

[cvburgess]

Looks like this is an active discussion in #1520

[zanona]

thanks for the reference @cvburgess, it appear that this discussion goes in more in-depth in the design and fusion between npm and bower. I think that is a nice idea as well, however the suggestion here would just act upon the configuration files itself not looking for merging one tool with another. But definitely great so see this being discussed. 👍

[sheerun]

As for me I'd gladly allow that for private projects.

For public projects you'd need to use bower.json for backward compatibility.

[acusti]

I really like this suggestion. As @cvburgess referenced by pointing to the issue about tighter bower / npm integration, it’s been explicitly endorsed by npm:

If your tool needs metadata to make it work, put it in package.json. It would be rude to do this without asking, but we’re inviting you to do it, so go ahead. The registry is a schemaless store, so every field you add is on an equal footing to all the others, and we won’t strip out or complain about new fields (as long as they don’t conflict with existing ones).

We realize this runs the risk of creating a jumble of incompatible metadata, so be reasonable: resist the temptation to grab a generic field name like “assets” or “frontend”. Use a label specific to your application, such as “mymanager-assets” or “mymanager-scripts”. If in the future we decide to more explicitly support your functionality and give it a generic field, it’s easy to maintain backwards-compatibility with the old name.

This is the approach taken by jspm, which tries to understand as much as possible from the existing package.json config and offers optional additional configuration options via the "jspm" property at the root level, much like @zanona’s suggestion.

As many have pointed out, maintaining many separate json configuration files is error prone, redundant, and a pain in the ass, so the idea of DRY-ing all of that up is very appealing to me. And naïvely, it seems to me that it shouldn’t be hard for bower to maintain backwards compatibility with bower.json by looking first for a "bower" block in package.json and falling back to bower.json, or vice versa. Is that feasible?

[quinncomendant]

Yes please +1

[Baldinof]

+1

[adamreisnz]

+1

I agree that it would be nice to have Bower read it's configuration and dependencies from package.json rather than it's own two separate configuration files.

[nick4fake]

This would make config much cleaner

[sheerun]

package.json can now contain bower configuration: #1711

[zanona]

Hey @sheerun, I believe this issue revolves something a bit more complex than just the configuration settings but also all project bower dependencies.

[sheerun]

Yeah, I know.. I just wanted to point it out.

[cvrebert]

👍

[jokeyrhyme]

NPM 3 is in beta, and will be released soon:
http://blog.npmjs.org/post/122450408965/npm-weekly-20-npm-3-is-here-ish

NPM 3 installs dependencies as flat as possible, unless there are conflicts:
https://github.com/npm/npm/blob/multi-stage/CHANGELOG.md#flat-flat-flat

Once NPM 3 drops the "beta" flag, there'll likely be little reason to favour Bower.

[mathiasrw]

@sheerun Sounds really great with

package.json can now contain bower configuration: #1711

I cant figure out how its implemented / find the documentation.

Is it like https://github.com/jspm/registry/wiki/Configuring-Packages-for-jspm#prefixing-configuration where we place a "bower": property in package.json and it overwrites root settings?

[zanona]

@mathiasrw here's an example package.json on how I use it:

{
  "name": "app-name",
  "version": "0.1.0",
  "config": {
    "bower_directory": "src/vendor"
  },
  "scripts": {
    "postinstall": "bower install -p",
    "prestart": "bower install"
  }
}

Hopefully it can help.

[mathiasrw]

@zanona Thanks for super quick response. I have a feeling the postinstall and prestart will interfer with the the use for regular node users of the package.

I will look into it and get back with feedback.

[teomaragakis]

+1 to @zanona, I like this suggestion too. package.json is more than enough.

Edit: Didn't see it was already implemented! Nice!

[beradrian]

+1. It doesn't make sense to maintain duplicate configuration files.

[lianyi]

+1

[VaibhavP17]

+1

[Download]

Having read this interesting article I myself was trying to move my configuration to package.json. However I found that lots of things are hard in package.json, especially because you can't reference one part of the json from another. So I came up with this little utility, pkgcfg to make working with package.json easier. It allows you to use tags in the package.json that are coupled to transformation functions, that will be invoked when the tag is encountered during parsing.

If bower were to read the package.json like this:

var pkg = require('pkgcfg')();

i.s.o

var fs = require('fs');
var pkg = JSON.parse(fs.readFileSync('../../package.json'));

Then all transformations inside the package.json would be executed and the result would be saved in pkg.

Then, users would be able to use package transformations like this:

{
  "name": "my-pakage",
  "version": "my-version",
  "outputFolder": "bin",
  "outputFile": "{pkg name}-{pkg version}.min.js",
  "outputPath": "{pkg outputFolder}/{pkg outputFile}",
 ..
}

It's very early for my little library so I don't suggest you use this as-is, but I stumbled onto this issue and it dawned upon me that if packages that depend on config in package.json would settle on a way of reading and parsing package.json that allows for such transformations, it would greatly empower all users.

What do you guys think about this?

[adamreisnz]

I think with Angular 2 and others moving to deprecate Bower in favour of npm for front-end package management, this issue might become obsolete in the foreseeable future.

Not trying to hammer on Bower, as it has served its purpose well over the past years, but it seems that with ES6 modules and improved build tools, it's no longer going to be necessary to have two different package managers for your projects.

[fabacab]

@zanona Thanks for sharing your example package.json to show this feature's use. My understanding of this feature is that, with the package.json file you showed, I should be able to do bower install or npm install and in both cases, bower will correctly understand that its directory configuration option should be set to src/vendor. I tried this out today but found that only the npm install command works as expected. When I run bower, Bower behaves as though I never set the directory config option, defaulting to bower_components. The result is that I still need to include a .bowerrc file in my project root despite using package.json anyway.

I am using Bower version 1.7.7.

Am I misunderstanding how this feature is intended to work or is there a bug in it?

/cc @mathiasrw

[zanona]

Hello @meitar,
Unfortunately so far, this still a proposal being discussed in regards installation and other features using a single package.json file. So I'm afraid it won't work at this time.

As per my second example to @mathiasrw,
That was indeed merged at https://github.com/bower/config/pull/23 and you can make use of npm's config setting in order to read env variables set in package.json.

But I'm afraid we are not there yet in regards a unified dependencies file 😄
I hope this clarifies your question.

All the best

[fabacab]

@zanona I think so. If I understand what you're saying, this means I was in fact misunderstanding and that a .bowerrc file is still required if I want to be able to invoke bower install instead of bower install --config.directory="src/vendor" regardless of whether my package.json file configures a bower_directory key. Thanks for clarifying for me. I look forward to a more unified system in the future. :)

[zanona]

@meitar actually, that does work. So perhaps I misunderstood your question :)
But keep in mind that for bower to understand which directory it has to install it, you must run bower through an npm script. This way bower will understand that npm is setting an env variable in the name of bower_directory for example, prefixed with npm_package_config_ and install it properly.

Re-enforcing last my example:

package.json

{
  "name": "test",
  "version": "1.0.0",
  "config": {
    "bower_directory": "src/vendor"
  },
  "scripts": {
    "bower-install": "bower install",
    "bower-install-moment": "bower install moment"
  }
}

When running npm run bower-install-moment, you will see bower will correctly install the dependencies inside src/vendor directory. When running npm run bower-install, bower will install all dependencies listed in bower.json file under src/vendor directory.

Overall, that PR was a replacement for .bowerrc file. But it has to run through npm, so it can set the env variables for you.

Does that make sense?

[fabacab]

Overall, that PR was a replacement for .bowerrc file. But it has to run through npm, so it can set the env variables for you.

Yes. My confusion was that I thought you did not have to run bower through npm, but rather could run bower directly. As you described, this is not the case.

[sheerun]

Bower is deprecated and we recommend using Yarn or Npm that supports package.json