Implement automatic fixes

[cartant]

Implement automatic fixes

[cartant]

If you have fragile code, I'd suggest using a central file into which all imports are made. The central file should be imported as soon as possible - that is, as soon as possible after the application's start up. How to use a central file is explained in the README.

As you say, it ought to be possible to implement some automatic fixes. However, I cannot see myself allocating time to do this. Especially as lettable operators will soon be the preferred importing mechanism.

For some information on lettable operators, have a look at RxJS: Understanding Lettable Operators. They are in the 5.5.0 beta, so they'll be in the next release.

If you are interested in contributing, PRs are always welcome.

[cartant]

Closing this as the changes in v6 mean that many of the fixable rules are now redundant and rxjs-tslint includes rules that will convert/fix v5 imports to v6 imports.

[lazarljubenovic]

I've read about the all-imports-in-a-single-file, but wouldn't that mean that it might happen that a lot of code is run client-side (patching the prototype), even if those operators might not be used at all. I'm talking about a lazily-loaded modules of an Angular application. Maybe only a single module is using some of the operators, so why run that code?

This is why I prefer importing operators in the file they're used. Importing it twice won't run any significant code as it would first test if the operator has been patched.

I've seen the lettable operator, the new operators path for importing, and the pipe operator. This is just another patch before the real solution which is the :: or |> operator that will eventually make its way to ES. It looks like a temporary solution to me.

I've never tried implementing a fixable tslint rule, and I don't have time a the moment either. But in a few weeks, if somebody else doesn't do it already, I might try getting my hands dirty. Thanks for the quick response!

[cartant]

My understanding is that the bind (::) proposal is dead. The recent TC39 meeting seems to have indicated that the pipe (|>) proposal is going to go ahead. I'd be more inclined to say that pipe and the lettable operators are the solution and that |> will simply introduce an alternate, ES-standard syntax.

Anyway, I see what you are saying re: lazy loading modules. However, there is no test, as I understand it. As I remember it, the patching imports just stick the method into the prototype. You'll just have the operator implementations in potentially multiple bundles (i.e. there could be duplicates). Depending upon how many modules you have, how many operators you use and how they are distributed throughout, it could be that using a central file might be optimal - as operators would not need to be duplicated between bundles, etc. Obviously, only you can answer this, but it's something to think about (if you've not done so already). Presumably, you already have RxJS in some sort of shared bundle?