The Story:
We are using ESLint with a set of different plugins. Long ago, in a specific JS-file (page object for Protractor) one of the rules was disabled via a comment at the top of the script:
/* eslint-disable protractor/no-by-xpath */
because there was an xpath() method used that violated the no-by-xpath and at that time we have not found a way to workaround it and we simply disabled the check.
The Problem:
Nowadays, the page object source code changed and there is no xpath() method used anymore. But, the rule is left disabled since the comment disabling it is still there.
The Question:
Our goal is to find the places in the source code where rules are disabled, but not violated. Does ESLint provide anything to report that? How would you approach the problem?
Would appreciate any insights and hints.
No, ESLint doesn't provide anything for this. This feature has been requested a few times, but was deemed unfit for ESLint core. Suggested way of doing something like that would be to create another tool that uses ESLint's Node API, and does two runs on all of the files, once with --no-inline-config flag on, and once with that flag off, then compare results and if files with inline eslint configs don't have any differences, then comments can be removed.
Related
I've created a es lint plugin that provides me with a rule which checks that provided import is not in a dynamic list of blacklisted imports.
The list is loaded from a JSON file.
Currently I am loading this file in the create method of a rule, but the rule is being recreated for each file, which in turn makes the linter slow.
I've found the following text in the ESLint documentation, but no other mention of a way to share some global object within an invocation of the linter.
https://eslint.org/docs/latest/user-guide/configuring/configuration-files#adding-shared-settings
ESLint supports adding shared settings into configuration files.
Plugins use settings to specify information that should be shared across all of its rules. You can add settings object to ESLint
configuration file and it will be supplied to every rule being
executed. This may be useful if you are adding custom rules and want
them to have access to the same information and be easily
configurable.
Is this supported? I've tried exporting a settings object in the index.js of the plugin, but it is not being picked up at all.
module.exports.settings = {
"sharedData": "Hello"
}
Looks like I already have a workaround, but wondering if someone will come up with a better solution.
What I did in the end was to load the configuration in the index of the rule itself, which is loaded at the start of ESLint.
Instead of depending on context.getCwd() I've fallen back to _dirname. Which proved to be enough for my use case.
I've just made a load of updates to a project and changed the TypeScript, ESLint rules etc. One thing I did was introduce the no semi-colon rule.
Now there are warnings/errors about every single semi colon still in the project (obviously this is what I wanted). There are also errors related to the TypeScript config changes I made. But I don't want to fix them all in 1 PR as that will be massive.
Is it possible to ignore these issues unless you open / edit the file somehow or what is the best way to achieve this?
I am collaborating on a git-sourced, maven-managed Java project with differing code styling preferences with users using multiple IDE's (note 1).
Is there a tool or IDE configuration that will allow code to be viewed and edited using style-1, but committed to SCM using style-2?
My research points me to 'no', but a solution combining git hooks and Checkstyle/jrefactory might be possible.
So if 'no' to above, is there a tool/process that will perform the TBD process actions below?
The checkout process flow for User1 would be:
git pull
TBD process formats code to User1 style-1
User1 works in their preferred IDE with style-1 settings
The commit workflow for User1 would be:
User1 is ready to commit/push code
TBD process formats code to standard format style-standard
git push
Note 1: multiple IDE's = Eclipse, IntelliJ, Netbeans.
Note 2: My question differs from this question in that I'd like to focus on an IDE-related solution, since forcing the minority of standards-divergent users is probably a more efficient solution.
Note 3: Acknowledging that this shouldn't be done for best-practices-reasons. However, if you grant that it's time expect more flexibility from our IDEs and SCMs, this question is intended to explore those solutions.
First of all, you really shouldn't do that. Codestyle wars are bad for any project, and it is best to decide upon one codestyle that everybody must use. It is simple to configure IDEs to automatically apply the specified codestyle at every filesave, so the developers don't have to write code in the target codestyle themselves, they can let the IDE do that for them. True, this doesn't solve the fact that they'll have to read code in a codestyle they don't yet like, but it's a lot safer than having invisible automatic code changes; that's a major source of bugs.
Maybe you can use Eclipse's code formatter from the command line to apply a different codestyle. You'd have to set up git hooks, make sure everybody has Eclipse available, and provide the proper configuration files for their preferred codestyle. You'd need hooks both for post-checkout and pre-commit, one to set up the user's codestyle, the other to commit in the central codestyle. To go one step further, you can play with the index to add the formatted code so that it doesn't include style differences in git diff (although they will show up in git diff --staged).
Again, you shouldn't do that.
I agree with Sergiu Dumitriu in this not being a very good idea. But still git provides exactly what you are looking for. Even though this will only work if your central coding style is very well defined and strictly followed. Here’s how it works:
Git provides smudge/clean filters. They allow you to pass all code through a so-called “smudge” filter on checkout and reverse that with a “clean” filter when code is added to the staging area. These filters are set in .gitattributes, and there is a repository-local version of that file available in .git/info/attributes.
So you set your smudge filter to a tool that will change the code to your personal coding style on checkout:
And your clean filter will convert the code back to the central coding style on checkin (more precisely: when file are staged):
It is very important, that smudge -> clean is a no-op / generates the original file again. Otherwise you will still check in format changes every time you change a file.
Using smudge and clean filters will retain all the functionality of git (including git diff etc). You can find the full docu in git help attributes
I need confirmation on the following theory. According to TS docs, there are two options that can be set in tsconfig.json.
--allowSyntheticDefaultImports: Allow default imports from modules with no default export. This does not affect code emit, just typechecking.
--esModuleInterop: Emit __importStar and __importDefault helpers for runtime babel ecosystem compatibility and enable --allowSyntheticDefaultImports for typesystem compatibility.
When I google around, I see both being set to true (at least in regard to the behavior I'm aiming at). However, as far I understand the docs, TS and transpilation to JS, it makes no sense to use them both.
The way I figure, I might use the latter only and entirely remove the former. However, being cautious and humble, I'm not entirely certain and worry that I'm doing something less bright without realizing it at the moment.
I fear that it's something inappropriate that's going to bite me in the donkey later on causing hours of lamenting and hair-pulling while desperately trouble-shooting. The basis for the skepticism is that both options are available, so I'm inferring that there are four cases where all the combinations (true/false etc.) are required but I can't imagine which they are.
Is it entirely safe to skip --allowSyntheticDefaultImports if --esModuleInterop: true in compilerOptions? ANd if so, why do we have that option?
Bonus question: when is it required with all the four combinations (true/false) for those two options?
If you mean can you leave allowSyntheticDefaultImports undefined and define only esModuleInterop, the answer should be YES moving forward, but there has been an issue with this. PR #26866 seems to be a fix, only merged September 17, so it there may be some risk in the short term.
As why both exist, I believe these were both a part of addressing compatibility issues with imports of Babel-transpiled modules, the original PR added the allowSyntheticDefaultImports option to certain compile-time messages, but in practice didn't address the runtime behavior of the imports. So --esModuleInterop was added later. See TypeScript-Handbook/#816 for discussion of how to update the docs...
Well, my understanding is that the allowSyntheticDefaultImports is for being able to load CommonJS libraries in a simpler way if you target es6+ (in dev time) while esModuleInterop is for simplifying these imports (in runtime) if you target for example AMD (like I do).
According to the docs you shouldn't need to specify allowSyntheticDefaultImports explicitly if you have esModuleInterop enabled, but the reason I had to enable also the allowSyntheticDefaultImports is that Resharper seems to look at that that flag when doing syntax checking in Visual Studio. Sure it built and worked ok anyway with only esModuleInterop, but I got a lot of red warnings from Resharper until I enabled also the other flag.
According to the relevant documentation here : https://webpack.js.org/guides/typescript/, both options have different significance. Based on the project code and dependent library syntax, either/both options may be required.
/* eslint-disable */ is the inline comment that disables/ignores all the eslint rules in a js file. Similarly is there any way to disable all jslint rules with inline comment within a js file?
TL;DR -- No.
You used to be able to have JSLint ignore sections of code, but that was removed no later than April of 2013.
Here are some options:
Roll your own ignore
In another answer, I've shown how to hack JSLint yourself if you really really to recreate this functionality. You'd probably have to change some line numbers, but you get the idea.
Id any code smell
The real question, however, is what specifically is it that you want JSLint to ignore? Often there's a code smell associated with wanting to skip something that you might, on further consideration, prefer to fix another way. Or if there's a specific JSLint option that matches what you want to skip, you could turn that option on.
"Quarantine" your code
As an alternative to turning JSLint off for a few lines if you know you want to keep the code, I often put utility functions that, for whatever reason, aren't JSLint happy, in a separate file so that I can have clean files elsewhere in my codebase.