Skip to content

Warnings API for deprecated features#918

Closed
raphamorim wants to merge 5 commits into
qunitjs:masterfrom
raphamorim:feature/warnings-for-depreacted-features
Closed

Warnings API for deprecated features#918
raphamorim wants to merge 5 commits into
qunitjs:masterfrom
raphamorim:feature/warnings-for-depreacted-features

Conversation

@raphamorim

Copy link
Copy Markdown

Ref: #881
Please don't merge this PR yet

I will finalize the PR if you have no problems with this implementation.

  • done() return all warnings.
  • Deprecated warning to start
  • Deprecated warning to stop
  • Deprecated warning for reset (this might need an extra discussion before removal, but it's deprecated)
  • Deprecated warning for asyncTest
  • Deprecated warning for global call test()
  • Deprecated warning for push
  • Deprecated warning for init
  • Deprecated warning for global call module()
  • Module hooks setup and teardown calls
  • Deprecated warning when use duration property in testDone
  • Assert methods on the QUnit and global objects
  • Logging callbacks being assigned with new values instead of called as functions

@leobalter leobalter changed the title Warnings for depreacted features [WIP] Warnings for depreacted features Jan 12, 2016
Comment thread src/test.js Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the console.warn call needs to be abstracted. Otherwise you'll need to check for it every time you trigger a warning.

Also, the messages could be stored on a dictionary object, easier to keep.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to implement this idea in aee09a2, what do you think?

@leobalter

Copy link
Copy Markdown
Member

We should focus initially on the warning abstracted implementation and then on the places we should have it.

The implementation should consider:

  • It can be toggled off (probably trough the config object)
  • Avoid changing any other external part of the API, including function signatures
  • It might - or not - be exposed (maybe through a QUnit.warning method). It's good if it's easy to export.
  • The deprecation messages can stored on a object, easier to find and change them if necessary. (e.g.: QUnit.warning.deprecated)

In the mean time, I should provide a complete list containing all the deprecated parts, including:

Needs discussion or implementation:


I need to check if anything is missing but this list is at least closer to reflect all the pre-2.0 deprecations.

@raphamorim

Copy link
Copy Markdown
Author

Sorry about delay :octocat:

Comment thread src/warning.js Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you may blend this warningMessage to the if statement above. It cost less to check for it before at first too.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated: a6a8c1b

@raphamorim

Copy link
Copy Markdown
Author

I agree with you that's not abstract. But in the case of the test method I would like to take this message to use in new Test(), to get this warning in done()

Like:

new Test({
   warning: warningMessage,

So the best approach is:

var warning = QUnit.warning.deprecated.test;
QUnit.warning( "test" ); // or "qunit-test"

Or: In addition to print, return the message

var warning = QUnit.warning( "test" );

Comment thread src/core.js Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may avoid the new warning variable calling the function directly with it, less use of memory.

Also: I still believe it's better to map the messages as string keys, the point is that we may want to trigger only once for each warning. If you find another way to solve this (the single trigger) you don't need to worry on the key map.

@leobalter

Copy link
Copy Markdown
Member

Ouch! some bugs found on legacy browsers. https://travis-ci.org/jquery/qunit/builds/106548000

The Warning API is getting great, we're close to move this forward.

@raphamorim

Copy link
Copy Markdown
Author

@leobalter can you check out the latest changes?
I will see this bug in IE7 and start writing tests for this PR :) :octocat:

@leobalter

Copy link
Copy Markdown
Member

I need two udpates:

  • a rebase with the master branch.
  • please make each warning trigger only once. I can't even check the CI the way it is. :)

Extra (probably for an extra PR in the future): you may try using QUnit.stack to mention where the first of each kind of deprecation has happened.

@raphamorim raphamorim force-pushed the feature/warnings-for-depreacted-features branch 2 times, most recently from 0de40ca to 2d6e227 Compare February 17, 2016 03:14
@raphamorim

Copy link
Copy Markdown
Author

Updated @leobalter :octocat:

@leobalter leobalter changed the title [WIP] Warnings for depreacted features Warnings for depreacted features Feb 18, 2016
@leobalter

Copy link
Copy Markdown
Member

We are close. Now we need to disable the warnings on the regular runs.

Maybe a QUnit.warning.off() being called on the main html test files (at least on test/index.html). Then, exclusive tests to check every warning (running on an isolated files, maybe a legacy-warnings.html and legacy-warnings.js).

The other improvements might come after these changes, potentially on another PR.

Comment thread src/test.js Outdated
}
}

QUnit.warning( "testDone-duration" );

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Warnings shouldn't be generated when there's nothing the user can do about it. I'd like to see this appear only in a getter for duration where Object.defineProperty exists.

@Krinkle Krinkle changed the title Warnings for depreacted features Warnings for deprecated features Feb 21, 2016
@raphamorim

Copy link
Copy Markdown
Author

@leobalter about the tests for QUnit.warning, do you think it's better to create a separate file (warning.html for example) to test individual cases?

@leobalter

Copy link
Copy Markdown
Member

yes. I wanna make sure we trigger warnings only on isolated cases.

This will help us to update the main tests before the next major release.

Comment thread test/amd.html Outdated
});

require( [ "qunit", "./amd" ], function( QUnit, tests ) {
QUnit.warning.off();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these specific tests should not worry about triggering it off. That should occur only for the main test or anything else that are still covering deprecated API.

@raphamorim

Copy link
Copy Markdown
Author

@leobalter see the lastest updates. Chek if this tests make sense to you? :octocat:

@raphamorim raphamorim force-pushed the feature/warnings-for-depreacted-features branch 2 times, most recently from ea7a6a0 to 2191cfc Compare February 25, 2016 02:37
Comment thread src/export.js Outdated
return QUnit[ key ].apply( this, arguments );
};
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be removed

@leobalter leobalter changed the title Warnings for deprecated features Warnings API for deprecated features Apr 20, 2016
@raphamorim

Copy link
Copy Markdown
Author

@leobalter check last changes :)

@leobalter

Copy link
Copy Markdown
Member

there's still some pending comments above, like: #918 (comment)

Comment thread test/autostart.html Outdated
times = {};

( function() {
(function() {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Undo? Seems like an accidental change.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated: 21cd239

@trentmwillis

Copy link
Copy Markdown
Member

Overall this seems okay to me, just a few minor comments

@trentmwillis

Copy link
Copy Markdown
Member

Sorry for letting this sit for so long. @leobalter is this still desirable/needed? I wasn't super involved here, so I'm unsure what the entire goal of the API was. I'd be fine to just use a simple warning as well for things like #986.

@leobalter

Copy link
Copy Markdown
Member

Makes more sense for now. Looking at this seems the warnings API is overkill at this point.

@raphamorim I'm closing this for now, thanks for the hard work and I'm sorry to not help with it so much.

@leobalter leobalter closed this Dec 6, 2016
@raphamorim

Copy link
Copy Markdown
Author

No problemo :)

@raphamorim raphamorim deleted the feature/warnings-for-depreacted-features branch December 6, 2016 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

5 participants