-
Notifications
You must be signed in to change notification settings - Fork 10
feat(comments): implements control directives through comments #18
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
Conversation
|
That looks pretty cool! thanks. I'll look at your changes in the next days. (busy at work) |
d2e0c08 to
6b3065f
Compare
…ray.prototype.indexOf
6b3065f to
2ab09b5
Compare
|
I realise that I need to migrate the travis CI to get the tests running again. Pushing a small update on the readme to get builds running. |
|
Alright, I see that current eslint version was not working for node 6 and 8 already. Do you mind if I drop support for these? (I saw you provided polyfills) @elchininet |
|
Hi @AoDev, I‘ll fix the Eslint errors. I added the polyfills because when I tested the code in Node 6 (we have some old projects using this environment) |
|
Hi @AoDev, the Eslint errors have been fixed in the last commit. |
|
Ah, I get your comment now. The current Eslint is failing under old node environments. Well, you can drop support if you want. Maybe it would be good to have the code written in ESNext and compile the package to ES5, but this can be done in a separate pull request. |
|
@elchininet Ok, since the problem is actually eslint but cssbyebye itself is fine with old node versions that you still use, I'll publish as a minor update on semver. (no breaking change release) I'll see what to do with eslint later. If I downgrade it or just don't pay attention at failing lint for node 6 and 8. If you setup prettier you can format the files with it, so you won't have lint issues next time. |
|
Thanks, @AoDev, just let me know if you need something else from my side. |
|
@elchininet I've published the new version to npm. (v3.1.0) |
|
@AoDev, that‘s great. I‘ll test it very soon. |
In one of our projects, we wanted to remove all the rules prefixed by a specific string, but at the same time, we wanted to maintain this prefix in a group of rules for internal reasons. It was impossible to do this through regular expressions due to the extension and the similarity of the rules that we wanted to remove and keep.
It would be easier to ignore the rules contained in a certain block and remove all the rules that match the criteria outside it. This pull request implements this through control directives that should be placed in comments:
Ignoring a single rule
options
input
output
Ignoring a block of rules
options
input
output