There are methods of doing things we want to warn people are going to be deprecated in upcoming major releases of RxJS. Currently we don't have anything in place to report these problems to the user in such a way that it doesn't intrude on production.
Ideally a solution for this would:
Rx.min.js was being usedLooking for any thoughts, ideas or prior knowledge of how to go about this. Especially from other library owners that may have already solved this problem.
This is a critcal thing for RxJS to advance in the most friendly way possible
This probably requires flag checking as similar to react does it for production build, let configure it by runtime, I guess? not sure what other approach can make prod / dev builds.
yup process.env.NODE_ENV !== 'production' is the way to go.
Would like to help. Do you have a list of things or a special annotation of what should be deprecated?
@pablolmiranda this issue is more about constructing foundational logics how to display those. Initial issue body contains necessary condtions we'd like to introduce.
In what folder do you want this implemented? Also, would it be OK to add something like react has, when the library is minified? ( giving you a link that you could click on Errors, depriciations and such )
@kwonoj How do you want this logic to be constructed in relation to, say a function in Observable.js ( imaginary example ) that we should warn the user about?
In what folder do you want this implemented?
Not sure if I get this right, but probably under util maybe? or directly under src?
Also, would it be OK to add something like react has, when the library is minified? ( giving you a link that you could click on Errors, depriciations and such )
Eventually it'd be good to have like those but I guess that's not immediate goal now.
How do you want this logic to be constructed in relation to, say a function in Observable.js ( imaginary example ) that we should warn the user about?
That is excellent Q, reason issue's staying we haven't made actual changes yet - we only have requirement of what we want (refer issue body) but we don't have preferences of how. as long as approach satisfies our need + shouldn't touch performance, I think it'd be ok to go.
I was thinking something like either referencing to the actual function name / call. If the source code is still in the codebase, we could add the stacktrace to the error log instead of just complaining about the name @kwonoj
@ev1stensberg we have several different builds and some build like UMD minified won't have original calls name.
FYI @robwormald had mentioned there would be complications that affect Angular if we used the process.env.NODE_ENV pattern. Something about Closure Compiler not supporting, but hopefully he can elaborate here.
A quick google suggests you can provide it to CC by using --define="process.env.NODE_ENV='production'" and including something like this:
/** @const */ var process = {}
/** @const */ process.env = {}
/** @define {string} */ process.env.NODE_ENV = 'debug';
I haven't tested this though and Rob probably knows the caveats.
Maybe the best thing to do, is to extend the classes to contain the depreciation class
I think that modern IDEs are taking care of some of this... and I believe that lint rules can do some of the work here as well. Closing for now.
Most helpful comment
yup
process.env.NODE_ENV !== 'production'is the way to go.