question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Remove opinionated configurations

See original GitHub issue

In ESLint it is common to have eslint-plugin-* project that provide custom rules and eslint-config-* projects that provide custom configurations (aka. rulesets). IMHO this project should only provide the custom rules for Ember projects, but no opinionated configurations. Instead opinionated configurations should be provided by projects like https://github.com/simplabs/eslint-config-simplabs and https://github.com/DockYard/eslint-plugin-ember-suave.

If we decide that we want to keep the configuration here then we should discuss what rules to recommend since this is an official Ember CLI project now and people are apparently starting to adopt those recommendations (see https://github.com/emberjs/ember.js/issues/15590#issuecomment-323342930)

/cc @rwjblue @michalsnik

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:5
  • Comments:7 (6 by maintainers)

github_iconTop GitHub Comments

3reactions
rwwagner90commented, Sep 5, 2017

FWIW, I would be in favor of voting on rules and doing some sort of RFC process or something, that way we can recommend a preset for ember projects to try to standardize things across the community. Everyone is going to have different opinions on things like spacing, etc, but rules that are good Ember practices should be an easy set for most people to agree on enforcing, I, for one, would be fine giving up some of my own Ember preferences, like using this.get for hopefully gaining more consistency across projects.

3reactions
jbanduracommented, Aug 31, 2017

I guess that the most likely candidates to be turned off as being too opinionated would be use-ember-get-and-set and all the order-in-* rules (I still kind of like the idea of keeping them, but switched off by default). I feel that all the others provide real value, such as preventing unexpected behaviour or warning about deprecations and could be another way for the ember core team to provide additional guidance for developers when introducing deprecations and/or introducing new features. WDYT?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Remove too opinionated config [#3207019] | Drupal.org
Problem/Motivation There is optional config that seems to accidentally hold some very opinionated settings. Usually you just create your own entity browser, ...
Read more >
Opinionated or Not: Choosing the Right Framework for the Job
In this article, we'll look at some opinionated versus non-opinionated frameworks and what use cases make sense for taking either path. We'll ...
Read more >
Remove opinionated settings from block markup · Issue #84 ...
As TT3 is focused on style variations, it would be good to remove as many opinionated styles from the block markup as possible....
Read more >
more configuration, less unchangeable opinionated defaults ...
One workaround is to write a Function to remove the Link header, or (once an update lands), add ! Link to _headers for...
Read more >
architecture - What is opinionated software? - Stack Overflow
Opinionated frameworks usually remove the burden from developer to reinvent the wheel or rethink the same problem again and again and thus help ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found