+1, so frustrating

+1

Ah, the dreaded post to [object Object]. Been there. Pretty easy to recognize by now, but I'm 100% in agreement for a warning to help people who haven't already made that mistake 100 times.

I really wish we didn't have the "shortcut" methods at all, they just make things worse. Can you pretend they don't exist? You can also use $.post = undefined or other stubs in your own code to ensure they're not called.

We're not going to start checking args at runtime and spewing console warnings, period. Take a look at the code for the shortcut methods and see how much code it takes to make them accept an object. If it's not too much we could consider it.

You'll get no argument from me about those existing, usually wrap $.ajax up in my own facade but that's not really to the point. As long as that stuff exists people will keep using them incorrectly and wasting many hours debugging by accident.

I take it you're saying that if I do a PR for this it will be considered?

+1

Yes, be sure to include some unit tests.

Also, stop the annoying +1 guys.

👍 stop all the +1's

Just to provide a timeline, we'll need a PR in the next week to be able to land this in the next version. We'll also need updates to the docs for $.get and $.post adding a new signature for Object, but it seems like several people want to see this happen so I hope they'll pitch in with a docs PR. You can probably get what you need from the $.ajax docs entry.

Yeah, I've been trying. I just can't seem to get the async tests passing reliably. I always get between 3 and 7 failing tests and needing to constantly restart php.

Been asking around in #jquery-dev and it seems like other people have issues with these as well.

I suppose you guys are aware your testing infrastructure is a mess :)

Do you have a recommendation on workflow for this type of thing?

@gmauer You can either ignore these few errors you have or you need to
create a full setup with a proper Apache serwer - the built-in PHP one has
limitations that sometimes hit the edge cases in our setup. There are links
in the README to project automating that for you.

The more elegant solution would be to switch to a server running in Node
but that may require a lot of effort judging by how many PHP tests we have
so this may not happen soon.

@togakangaroo If you have it that close and some random tests are failing, go ahead with a pull request. I wish our test infra was more robust, but most people get that by mocking the tricky parts. Ajax in particular can't be mocked because often we need to test our workarounds to obscure XHR bugs and the like.

@togakangaroo Yeah, the built-in PHP web server is a little underpowered. Apache & nginx both work well. The official jQuery docs recommend installing (L|M|W)AMP on your development computer. Personally I've been using a Vagrant VM with nginx.

@mzgol Switching over to a Node server would be awesome. Is there a ticket for that?

@mzgol Switching over to a Node server would be awesome. Is there a ticket for that?

I don't believe it is. We haven't really discussed it seriously due to the effort needed.

Just created: #1999

I think the difficulty of getting an environment up and running for jquery development is absolutely a stopper to people contributing.

I'm saying the following not in order to complain, but to hopefully help the team see some of the pain points that could be addressed. And also to complain a bit.

I'm mostly a js and .net developer working on Windows. I've done php but ages ago and I know some Linux basics but its far from my comfort-zone. Installing php just to run tests was annoying enough, if I had to install and figure out apache setup I definitely would have given up.

At the moment I'm about 11 hours into a PR that ultimately changes two lines of code. That's with me coincidentally catching the right people on irc (no way I would have known that php -S 0.0.0.0:8500 is the special incantation on my own). Even then, in the ajax module I was getting frequent and non-deterministic test failures. I ultimately had to comment out most of the tests just to be able to test my specific feature. In addition, I found I had to read source on a lot of the testing infrastructure as it was not at all clear how to use things like ajaxTest and its expect parameter.

Next, I'm a fan of build tools, and building jquery was a breeze. However, testing was not. Testing was not just a matter of npm run tests, but starting php in one terminal, then in another terminal grunt watch, then directing my browser to the right page, and figuring out what options were necessary to get the right files to load ('use unminified' for example). It would seem like grunt can at least start the server and open the right page with the correct configurations for you, if not run tests in a headless browser full-on.

I'll also note that I still haven't been able to get the documentation VM running. When I attempt to grunt deploy the api into the VM I get an error that I need xmlsoft. On windows, this means installing a virtually unknown piece of software (its not even in the chocolatey package manager), maintained by a single developer, on the machine that I run all my work VMs from. Not something I'm comfortable doing. So now I'm working on setting up a VM inside of which I will try to deploy the vagrant VM. I'm running into issues with that (vagrant VM won't finish starting) that I now have to debug in order to continue.

I realize that it's all a house of cards, but it would seem in order to enable contributions from people who are not in the php space (and also happen to know how to use node/grunt) a significant amount of effort could be justified. Even if the solution is just to package a single VM with all the tools necessary to develop jquery built in.

@togakangaroo I develop with Windows too. Did you try installing WAMP?

@togakangaroo thank you for writing this up. Getting started and having a stable setup is the hard part. Now that you've been hazed I hope you'll stay around and continue to contribute, maybe even help us to solve some of these issues.

I definitely think the process is harder than it should be, but since we need to actually test in a bunch of real browsers it's never easy. To make things worse, we need a real server to talk to so that we can send back specific requests and test our browser fixes for AJAX patches inside jQuery. Sometimes even the configuration of the web server becomes an issue, we've had some issues moving our tests from Apache to nginx in the past.

I do my work on Windows as well. WAMP is definitely the way to go, along with msysgit. I've had my share of troubles with the docs VM as well and at the moment I don't have a working setup either. If you can put together your (untested) suggestions for docs in a pull request we will take it the rest of the way.

Simplifying the test setup is being discussed in #1999.