Update bower.json

[amfg]

Include forgotten js/base.js

[rigdern]

@amfg Thanks for the PR. It looks like you may be trying to fix #2.

Can you describe how you are consuming WinJS thru bower that is causing this problem?

According to the bower documentation, there should only be one entry in main per file type. It seems that this PR would be violating this rule.

Note that ui.js declares a dependency on base.js via the module system (both AMD and CommonJS) so we expected that to be sufficient and are interested in hearing more about your problematic scenario.

[amfg]

Yes, this was an attempt to fix #2.
We are using gulp to build/serve our project, winjs has been installed through bower --save.
I can see the declaration in ui.js which, strangely enough, gulp does not see.
We did not have any problem like this with other libraries so I assumed it is this config to blame.
I believe this would be worth looking into someday, until then I will use this patch which solves the issue for me.
.

[rigdern]

@amfg What gulp task is not picking up WinJS's base.js? Can you provide a small sample of a gulp file that could repro this bug?

[sondreb]

There are multiple libs that does not pick up the base.js, two of them are:

grunt-wiredep (automatically injects .js links into .html file)

and

main-bower-files (pipes the main outputs from all bower components)

The second is a gulp task while the first is grunt. Works fine when manually editing the bower files inside the winjs folder. Do you still need me to make a full repro?

[jdalton]

\cc @sindresorhus Do you have any guidance on this?

[sindresorhus]

Nothing other than using npm instead. I don't use Bower.

npm uninstall -g bower && rm bower.json && echo '\o/'

[sindresorhus]

// @stephenplusplus

[stephenplusplus]

Bower recently changed its spec, but didn't leave the tooling ecosystem (where wiredep lives) any options for packages that do the right thing and conform to it (where winjs-bower lives). See bower/spec#47 for attempts at solving the problem.

For wiredep and other tools that support the community-created overrides property, you can consider something like one of these options:

{
  "name": "your-project",
  "dependencies": {
    "winjs": "4.1.0"
  },
  "overrides": {
    "winjs": {
      "main": [
        "js/build.js",
        "js/ui.js",
        "css/ui-dark.css",
        "fonts/Symbols.ttf"
      ]
    }
  }
}

or...

var wiredep = require('wiredep');

wiredep({
  overrides: [
    winjs: {
      main: [
        'js/build.js',
        'js/ui.js',
        'css/ui-dark.css',
        'fonts/Symbols.ttf'
      ]
    }
  ]
});

I'm not too familiar with this project, but as long as files are included in the Bower package that work for your app, you can use overrides to tell us to inject them.

More about wiredep + overrides: https://github.com/taptapship/wiredep#bower-overrides

[rigdern]

Thanks @stephenplusplus!

It sounds like WinJS is doing the right thing and there's nothing more for WinJS to do at this time.

You provided a workaround for apps and bower is working on a solution that WinJS can utilize in the future. Is my understanding correct?

[sondreb]

I just have to ask, what is the problem with having one additional .js reference in the "main" section of the project's bower file? There is already ui.js, ui-dark.css and Symbols.ttf in there, why can't you simply add base.js as well? Should all project that want to use WinJS, add ~13 lines of infrastructure code simply to include base.js in additional to the other files?

I agree with @sindresorhus on using NPM, but ASP.NET 5 beta uses Bower and if those developers want to continue to use bower, they have to do work-arounds for WinJS that are not required for most other dependencies.

Already told Microsoft to drop using Bower in the default template, though they rely on a few Bower-only packages for their standard ASP.NET 5 website, like this, which they really could put on NPM as well: https://github.com/aspnet/jquery-validation-unobtrusive

Edit: I read this on one of the links references above: "Now main should no longer lists all the files (The entry-point files necessary to use your package. One per filetype).". So I can understand the current tooling issue then... no fun.