Comments (5)
I assume the following would be a reasonable start.
{
"extends": ["eslint:recommended", "plugin:node/recommended", "prettier"]
}
Probably tucked inside eslintConfig
field in a package.json so we don't need to clutter the root directory any more than it needs to be.
Maybe there is some way we can have this config without needing to add eslint-config-prettier, eslint-plugin-node, eslint and to the package.json (and package-lock.json). I'd rather just have the latest version of those dependencies ran every time I wanted to lint instead of some pinned version.
from jomini.
Extending the recommended is reasonable, but it doesn't cover many very useful checks. Also, the "recommended" may be working on a style that's different from the existing convention here.
To set up the latest version instead of some pinned version, just use the >={version}
rule in package.json instead of ={version}
The linter configuration can be quite long, especially if you add a lot of plugins.
From what I've seen so far, looks like the common practice is to put it in its own file (.eslintrc
) as opposed to in package.json
.
Why do you care about cluttering the root directory? You can #26 if you're concerned about what happens when the package is npm install
ed.
Technically you can run a linter without any configuration per-project, so it runs with your personal global preferences. However, if you do it that way:
- You're not sharing it with other developers
- Other developers may have different preferences
- The linting can't happen as part of CI/CD
from jomini.
If we go with eslint, we'll obviously have to use eslint
configuration.
I'm reading the docs for eslint-plugin-node and it looks like a lot of these rules are already covered by the basic eslint. Which rules in particular do you want?
I'm reading the docs for eslint-plugin-prettier and it looks like a lot of rules are also already covered by the basic eslint, and some may conflict. Which rules in particular do you want?
In my personal projects, I go with just eslint
and eslint-plugin-import
, and it covers most use-cases very nicely.
from jomini.
I've implemented an .eslintrc (see pull request).
Here are a few issues I'd like to bring up for discussion:
- Which
ecmaVersion
are we targeting? Is this supposed to be run in a browser? or in a node environment? How far back to we provide backwards compatibility? no-prototype-builtins
is part ofeslint:recommended
, but turning it on flags existing code as an error (specifically various calls to.hasOwnProperty()
). Do we want to keep the rule off? or do we turn the rule on and fix the existing code?- The comparison operator (
==
) may do implicit type coercion, but the strict comparison operator (===
) doesn't do that. There are various instances of using==
in the existing code when===
could have been used. There's an option to turn on a rule to enforce that (eqeqeq
). - Do we care about magic numbers in the existing code? (
no-magic-numbers
) var
declarations imply hoisting. There's a rule that enforces putting them on the top of the scope, so that the implied hoisting is communicated. (vars-on-top
)var
can be replaced withconst
orlet
in newer versions of JS. Do we want to enforce that? (no-var
)- Arrow callbacks are more concise and intuitive in terms of scope (e.g.
this
keyword semantics). Do we want to replacefunction(){}
s with()=>{}
s where possible? (prefer-arrow-callback
)
from jomini.
I'm happy to accept PRs that updates code to conform to some eslint rule, but as of now I have yet to see a solution that minimizes the amount of cruft that is added to the project. Any solution would need to be less than a half dozen lines.
from jomini.
Related Issues (20)
- Binary format HOT 5
- Is it possible to get the file line number under which a given object is located? HOT 3
- Add Windows / Mac CI
- Investigate disabled `parse.js` test HOT 1
- Set up `files` field in package.json HOT 4
- Document somewhere that jomini is supposed to run in node and in browser HOT 1
- Empty objects not handled HOT 1
- Out of memory error when parsing large files HOT 6
- Manual fixes required for EU4 gamestate data before parsing HOT 3
- File Isn't Parsed Correctly HOT 5
- Question: Does the JSON pointer like strings support wildcards HOT 2
- Bug? Parsing map/area.txt HOT 2
- Is this repo able to return timeline data? HOT 4
- Getting geojson data of the current EU4 map? HOT 2
- Command line version? HOT 5
- How can I make this work with typescript and webpack HOT 5
- Feature request: Deno support HOT 6
- Incorrect types for slim package export
- Strings containing numbers become numbers HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jomini.