-
-
Notifications
You must be signed in to change notification settings - Fork 187
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
Expose report-related APIs in another package #39
Comments
I wouldn't mind doing this in theory, but it feels like the helper functions are sufficiently small and eslint-specific that it wouldn't be worthwhile. For example, all of the helpers use I don't think your proposed interface would work, because something like |
The return {
Program() {
if (!prettier) {
// Prettier is expensive to load, so only load it if needed.
prettier = require('prettier');
}
const prettierSource = prettier.format(source, prettierOptions);
if (source !== prettierSource) {
suggestedAPI.reportDifferences(source, prettierSource, {
reportInsert: (...args) => reportInsert(context, ...args),
reportDelete: (...args) => reportDelete(context, ...args),
reportReplace: (...args) => reportReplace(context, ...args),
});
}
}
}; We can call For TSLint vs ESLint API, see this. If you still think my proposed interface wouldn't work, I can send a PR here to show what it'd be in my proposal. |
See #40 for my proposal |
cc @zertosh, any thoughts on this? |
Sounds good to me! |
Currently, all the APIs are not exposed, so that it can't be reused by other linter-plugin, e.g. tslint-plugin-prettier (currently just copy-paste implementations from this repo).
It'd be better to expose report-related APIs in another package (since this repo has peerDeps for eslint), so that it can be reused in different linter plugin to have consistent behavior.
Suggested API
The text was updated successfully, but these errors were encountered: