New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal for additional APIs #6525
Comments
|
@nzakas both |
Maybe for clarity, we could have |
There's no need to remove plugins, though, because they do nothing on their own. The only consequence is when you enable a plugin rule or use a plugin environment. I just don't see why, even in the demo context, you'd need to remove a plugin. As long as you just don't use it, it makes no difference. I'm pretty skeptical that testing out plugins in the demo is going to work, so anything that is specifically for that use case I'd hold off on until you can put together a design for how its intended to work. As these would be public-facing, I don't want to add things because they seem like they're needed now and then be stuck with unnecessary or confusing methods. I can see value to a general |
Sounds good. We can start small and add as we need. Do you think it makes sense to have separate |
I think if we stick with Also, had another thought (and reinforces my belief that we should really discuss a design for the new, more powerful demo have you mind): I don't see any way that CLIEngine will behave in a browser environment. It seems like we might actually need a WebEngine to go along with it and that that object might be where we should be looking to add functionality for the demo. |
@nzakas While my only use-case is online demo, I don't think those APIs should be exclusive to demo only. For example, if somebody wanted to create rule configurator with a nice UI, they would need to get all schemas and metadata for rules. |
@ilyavolodin I don't like inventing use cases that we haven't encountered before. Trying to solve a problem that we're not in the middle of will lead to bad decisions. Let's focus on the use case you actually have because it'll be easier to evaluate solutions for it. If and when someone else has a use case that requires other stuff, we can evaluate at that point in time. |
Sounds good. In that case, primary use-case is online demo. Ability to retrieve list of all rules and schema/metadata for them would allow us to create more intelligent configuration selection interface. Let's skip plugins for now, since I don't know how something like that would work (although it's possible, since tonicdev already have an ability to load npm packages on the fly and execute them in the browser). P.S. I updated original request with only necessary APIs. |
I look forward to seeing some of these new APIs implemented. If we do, then we can have Is there anything blocking consideration of adding |
There's nothing preventing us from doing that right now. I think we only need |
@nzakas To get metadata directly from the rules, you need to be able to access all of the rules. That's not a huge problem from inside ESLint, but if you are using ESLint as dependency, that will be an issue. Also even from inside ESLint, getting metadata for plugin rules would not be easy. I think we also need |
@ilyavolodin sorry, I'm not sure what you're saying the problem is. Why can't I do this?
I'm unclear on why plugin rules would be different from any other case. Wouldn't that just be this?
If not, can you please be more descriptive and include some examples? I'm having trouble following this as an abstract idea. |
@nzakas I'm talking about
Do you want to change that and return a full rule from that API call? I'm fine with that, and in that case we don't need |
Ah, I was focusing on the first sentence in your description, "Should return all currently loaded rules." To me, that means you return whatever is To me, I'm not seeing a good argument for returning a subset of the rule information -- the size of that data really isn't a concern because we've already loaded it anyway. It seems like the only real difference from what you're proposing is the inclusion of all metadata instead of a subset and the creator function (which is already in memory). |
Sounds good to me. So let's have |
My only concern is normalizing between old and new style rules (irrelevant in the case of core rules, but relevant for plugin rules which may be old style). Could/should the API normalize that at all? (It wouldn't be too hard to normalize an old style rule to new style, for example.) Motivation: It would really stink for consumers to have to write |
I think we already normalize somewhere. |
@nzakas Now that you say that, I think you might be right-- I've seen it in RuleTester. What we need to make sure of is that the normalization happens before the rule is defined into the rules config object. |
TSC Summary:
|
Marking as accepted as per the discussion during today's TSC meeting. |
Is my understanding correct? |
@sarbbottam My understanding from the discussion above is that all of the core ESLint rules will always be loaded and returned by |
@randycoulman That's correct. Core rules should be always loaded. Plugins rules will only return if the plugin is loaded. |
Thanks @randycoulman, @ilyavolodin. I am not familiar with the code base, any pointer where should I start with? |
@sarbbottam I haven't looked around the code to see where would be the exact place to start with this, but in general this should go into |
Can we close this issue by #7669? |
Hmm... Why didn't it get closed automatically? Yes, this is now resolved. Closing. |
I would like to propose additional APIs. I'm not sure which object they should be attached to, as they don't seem to fit any of the current ones we have. Maybe
linter
, since they are all global.version
Should return current ESLint version. This is necessary to correctly invalidate session storage data in the online demo, and probably useful for tools as well
getRules()
Should return all currently loaded rules. If
CLIEngine.addPlugin
has been called prior to this API call, it should also return rules from plugin. Return should be an array of object with rule name, rule schema and current configuration.getRuleMetadata(null|string)
Should return metadata for all currently loaded rules (plugins included). Can be merged with
getRules
command.The text was updated successfully, but these errors were encountered: