Build: Add jQuery to dependencies

[Bajix]

jQuery is a dependency of jQuery UI and needs to be listed within package.json in order to create a dependency graph.

See stealjs/steal#971

[jsf-clabot]

All committers have signed the CLA.

[scottgonzalez]

This is wrong for everyone who uses npm, which is effectively everyone contributing to the project.

What specific problem are you trying to address?

Also, 16 hours over night is not a long time to wait for a response.

[Bajix]

This is wrong for everyone who uses npm, which is effectively everyone contributing to the project.

This is a baseless. jQuery is a dependency of jQuery UI, and by not including it as a dependency you're making an invalid package.json, and an invalid dependency graph. In fact, you're actually undermining npm by keeping jQuery on a technological pedestal.

Also, albeit maybe less relevant, I'd also point out that you're losing out on taking advantage of things like Travis CI + green keeper to automatically trigger PR's / tests for new versions of jQuery.

---

What specific problem are you trying to address?

I linked to the specific issue already. jQuery UI has an invalid dependency graph and that impedes any use-case that involves dependency graphs.

stealjs/steal#971

[scottgonzalez]

As far as I'm concerned, this is still an unsolved problem, though npm is working on a solution for how to work with front-end dependencies.

The fact is jQuery UI uses node for tooling. Listing jquery in dependencies means that we'll be requiring jquery to be installed for every contributor, when it's not a dependency for any of our node uses. We already have several copies of jQuery in the repo and every use of node when working on jQuery UI will use the ones in the repo and not the one installed by npm.

I personally hate the situation that the community has created, so you'll need to convince other jQuery UI maintainers that this is a beneficial change for us in order for this to land.

[Bajix]

...we already have several copies of jQuery in the repo and every use of node when working on jQuery UI will use the ones in the repo

So this issue is easily solved by using jQuery as a dependency within nested package.json files within the repo.

An npm script such as cd test/tests && npm update --cache-min=Infinity would do the trick. IE:

  "scripts": {
    "jshint": "jshint lib/.  test/*.js --config",
    "copy": "cd test/tests && npm update --cache-min=Infinity",
    "test:only": "npm run copy && npm run mocha",
    "test": "npm run jshint && npm run test:only",
    "mocha": "node test/test.js"
  }

---

when it's not a dependency for any of our node uses

Maybe not your node use cases, but certainly other people's node use cases. There have been some really good advancements in server-side rendering of single-page apps based around zones. In order to support this, the StealJS loader has env-base configuration overrides for loading packages with node. For something like jQuery, can-vdom is used to make a window object.

I have many projects utilizing isomorphic single page apps doing this kind of server side rendering, and in all of them anything jQuery / jQuery UI related requires special consideration. It would be very easy to remove this necessity.

I personally hate the situation that the community has created, so you'll need to convince other jQuery UI maintainers that this is a beneficial change for us in order for this to land.

They are straight up impeding the transition into a fully dependency managed ecosystem. That every dependency loader has a special section for how to do overrides for making jQuery & jQuery related things work isn't a good thing -- rather it's constant barrier of entry and one I had hoped jQuery 3 would've finally addressed.

[scottgonzalez]

So this issue is easily solved by using jQuery as a dependency within nested package.json files within the repo.

I definitely don't consider having 40 package.json files in a single repo an easy solution.

An npm script such as cd test/tests && npm update --cache-min=Infinity would do the trick. IE:

I'm not following how this helps, or how we get all 39 versions, or why we'd want to wait on npm for every test run.

Maybe not your node use cases, but certainly other people's node use cases.

Yeah, a lot of developers do a lot of things to find ways to make their own ideas work. I have no interest in supporting the myriad of ways developers have decided to manage their apps. I do have an interest in a single, sane solution, but so far the community is just adding instead (fracturing) of subtracting (standardizing).

I have many projects utilizing isomorphic single page apps doing this kind of server side rendering, and in all of them anything jQuery / jQuery UI related requires special consideration. It would be very easy to remove this necessity.

Yes, solving one problem for you is easy. Solving all related problems for all users is not. And I have no desire to play favorites here.

rather it's constant barrier of entry and one I had hoped jQuery 3 would've finally addressed.

How would jQuery solve the problem introduced by a dozen different loaders, dependency resolvers, bundlers, etc.?

[Bajix]

I'm not following how this helps, or how we get all 39 versions, or why we'd want to wait on npm for every test run.

You could do something more akin to seeding the cache w/ a specific version and automating the rest. Anyway, point taken - I hadn't looked into your specific testing needs too much.

I do have an interest in a single, sane solution

The sanest solution that has been proposed here is for the package.json dependencies array to representative of the actual dependencies of the main export.

Yes, solving one problem for you is easy. Solving all related problems for all users is not. And I have no desire to play favorites here.

Your perspective is off. Quite literally every loader plays favorites for jQuery & jQuery related projects wherein they explicitly demonstrate the need for things like manual dependency overrides.

How would jQuery solve the problem introduced by a dozen different loaders, dependency resolvers, bundlers, etc.?

Use package.json. Encourage projects to do the same. That simple.

The downside for contributors of having jQuery as a dependency are entirely negligible.

[scottgonzalez]

You seem to be missing a very important factor in all of this. jQuery UI is not really something anyone should ever list as a dependency. Sure, people do it, but it's wrong. You should list specific things, like dialog, as a dependency.

Anyway, as I've done in every other discussion related to dependency resolution and package managers, I will bow out as my stance is known by the rest of the team and I don't have interest in making changes to accommodate different tools all the time.

[Bajix]

You seem to be missing a very important factor in all of this. jQuery UI is not really something anyone should ever list as a dependency. Sure, people do it, but it's wrong. You should list specific things, like dialog, as a dependency.

I never said anything to the contrary. Actually, I'd go farther to say that jQuery UI should be split up with repos for each widget. I can help spec out how this would look if you're interested.

Anyway, as I've done in every other discussion related to dependency resolution and package managers, I will bow out as my stance is known by the rest of the team and I don't have interest in making changes to accommodate different tools all the time.

My recommendations aren't to accommodate specific tools - in this case it's clearly something that will be independently resolved through parent module configuration.

As far as I'm concerned, you haven't actually taken a stance, you've just resigned to the inconvenience of dialogue.

[scottgonzalez]

Actually, I'd go farther to say that jQuery UI should be split up with repos for each widget. I can help spec out how this would look if you're interested.

I know exactly how it would look and I'm not interested in managing several dozen repos for this project.

[Bajix]

I know exactly how it would look and I'm not interested in managing several dozen repos for this project.

Then allow others who are willing to do so. The help is there, me included.