Comments (5)
If you think that is a good/appropriate solution, happy to open a PR!
from eslint-plugin-ember.
How often does someone use eslint-plugin-ember without extending from our recommended
config? I assume the vast majority of users use our recommended
config and just disable a few rules they might not like.
However, I will note that we previously had a base
config which I removed in #1518 to simplify things. I haven't heard of any use cases for needing a base config, and no complaints since removing it, but your request is a potential use case for it.
Options:
- Add back a
base
config - Just copy this override for a one-off need
- Export just this one override so it could be used like this
overrides: [require('eslint-plugin-ember'].gjsOverride]
from eslint-plugin-ember.
I am not sure about how often, I would say that in this case, it seems like discourse is currently unable to use it because they have legacy syntax that causes the rules to error (I haven't investigated much more).
Personally, the idea of a base/minimal config for this kind of stuff seems to make sense.
The issue with copy-and-pasting is that the __GLIMMER_TEMPLATE
stuff is essentially an internal implementation detail of the ember eslint plugin that IMO we should try to hide as much as possible. (I know technically it's an implementation detail of the utilities borrowed from ember-template-import
, but from the user's perspective that should probably be considered an internal dependency here.) Especially so since that implementation detail is subject to (and probably about to) change.
I think exporting the overrides is okay, but it seems a bit unidiomatic for eslint in my experience, and from what I understand that's essentially what the "extends"
stuff is for. It seems like that's basically inventing another way to add back the base config without adding back the base config :)
from eslint-plugin-ember.
It's a fair point that a legacy codebase may want to use a base
config and selectively enable some rules on top of that, since our recommended config does target relatively modern versions of Ember (generally LTS versions from the past few years). However, I would still encourage any legacy codebase to flip this around--it's usually best to enable the recommended
config and then selectively disable incompatible rules--but I understand not everyone will follow that best practice of mine.
I agree that the solutions of copy-pasting and exposing an individual override are hacky for the reasons you mentioned. Those options could still be useful workarounds if we believed this was a rare, one-off need that we didn't want to officially support nor encourage. If, however, we decide we want to officially support this use case, then yes I agree restoring the base
config is the right way to do it.
from eslint-plugin-ember.
If you want to proceed with base
, it should mostly just be a revert of #1518.
from eslint-plugin-ember.
Related Issues (20)
- [email protected] detects single-line components as zero-line components HOT 3
- Parsing error for template tags within classes on v11.11.0 HOT 6
- Drop Recommended Rules for Deprecated Ember 3.x Features HOT 2
- Replace ember-template-imports with content-tag HOT 2
- New rule proposal: require-components-imports-pascal-case HOT 2
- config files in readme should not encourage top level config. overrides only.
- ESLint couldn't find the config "plugin:ember/gts-recommended" to extend from HOT 4
- false positives for `no-unused-vars` in `gjs` files, when using `<Component as |something|>` HOT 3
- gjs/gts Incorrect token mapping after handlebars HOT 1
- Support "Type aware" linting for gts files HOT 13
- "service" import not treated the same as "inject as service" HOT 1
- no-unused-expressions HOT 4
- Plan v13 Release HOT 4
- new "flat" configs contain invalid parser key HOT 19
- `@typescript-eslint` breaks after update to `eslint-plugin-ember` v12 HOT 19
- ember/template-no-let-reference HOT 4
- ember/no-runloop HOT 4
- New rule: prevent assignment of existing properties on a service (important for tests)
- @typescript-eslint/eslint-recommended not applicable to `*.gts` files HOT 1
- Should we provide a config that disables some rules from `@typescript-eslint/eslint-plugin`? HOT 11
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 eslint-plugin-ember.