Support the browser #16
Comments
The module "depd" does not support browser and it is not trivial to fix that. This commits adds a lightweight implementation of the depd "deprecate" function.
|
Yes, those are the easy ones :) The main pain point is how to do the repeat warning suppression and pointing to the caller, both of which are using call stack walking. What's nice about this module is that it doesn't warn only on first call, but rather for each unique caller callsite + calle callsite. This allows the user to run their program and collect at the deprecated calls in a single go, which things like node.js core deprecate make impossible since they only warn on whatever the first call was. Think I you are using a lib that calls a deprecated function. Then your code calls that deprecated function: since you can't change that other lib, you would like to know if your own stuff called the deprecated function. |
|
So thinking of it more, there are a few main things we need to gather first:
|
From my POV, all evergreen browsers (Chrome, Firefox, Safari) and Internet Explorer 8+ (that's the difficult part).
This should be pretty easy via https://ci.testling.com/, although I haven't used it myself yet.
Here is a tutorial you may find useful: http://substack.net/how_I_write_tests_for_node_and_the_browser The testling-ci docs makes me believe it should be very easy to setup the automated CI build: https://ci.testling.com/guide/mocha |
|
Awesome, thank you for the information! I'll check it out. I'll likely start with just the browsers that support access to the raw JS call stack first, and then look into what is needed to actually get it to work without access to the call stack. |
|
This module also requires support for |
Is this required for all module users, or only when calling
From my POV, I would prefer an implementation that works across all browsers, even if it (initially) provided less features than the Node version. However, since I don't have time to work on this feature myself, I should not complain either :) |
|
There is also a problem if you use a Content Security Policy, because Angular.js for example detects an active CSP and uses a fallback in that case. |
|
Interesting. Currently the reason for the |
|
Yes, I know, on stackoverflow there is no other way than |
|
@bajtos and others that are subscribed here, a new version of this module (1.1.0) is about to be released that adds support for web browsers via. Browserify/webpack by simply providing the API but in a "no-op mode". After that release, work will begin on bringing various features into the browser, but unless you really, really desire the features in the browser build of your module, you would be able to upgrade to 1.1.0 and remove any custom |
|
@dougwilson thank you for adding basic support for running the module via browserify. Since we have implemented a workaround that actually logs deprecation warnings (see browser.depd.js), I prefer to stick with that until |
I'd like to use
depdin LoopBack, a project that supports both the server (Node.js) and the browser (via browserify).There are two major problems why
depddoes not work in the browser now:process.stderris not available in the browser. index.js#L245-L250Error.captureStackTraceis Chrome-specific and not available in all browsers (PhantomJS 1.x is a good example). index.js#L375There are few minor details to work out too, but they can be IMO deferred until later:
process.envbased configuration to a browser way. Possibly vialocalStorageas "debug" does (docs)?process.on('deprecation', fn)won't work now.The text was updated successfully, but these errors were encountered: