Skip to content
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

"destructured" option for camelCase rule #3185

Closed
willrstern opened this Issue Jul 29, 2015 · 10 comments

Comments

Projects
None yet
8 participants
@willrstern
Copy link

willrstern commented Jul 29, 2015

when destructuring an underscore_spaced request:
const { category_id: category } = query;
camelCase errors that category_id is not in camel case

It would be nice to have a "destructuring" option, or just ignore when destructuring non-camel-case props to camelCase.

@eslintbot

This comment has been minimized.

Copy link

eslintbot commented Jul 29, 2015

Thanks for the issue! We get a lot of issues, so this message is automatically posted to each one to help you check that you've included all of the information we need to help you.

Reporting a bug? Please be sure to include:

  1. The version of ESLint you are using (run eslint -v)
  2. The source code that caused the problem
  3. The configuration you're using (for the rule or your entire config file)
  4. The actual ESLint output complete with line numbers

Requesting a new rule? Please be sure to include:

  1. The use case for the rule - what is it trying to prevent or flag?
  2. Whether the rule is trying to prevent an error or is purely stylistic
  3. Why you believe this rule is generic enough to be included

Requesting a feature? Please be sure to include:

  1. The problem you want to solve (don't mention the solution)
  2. Your take on the correct solution to problem

Including this information in your issue helps us to triage it and get you a response as quickly as possible.

Thanks!

@gyandeeps gyandeeps added the triage label Jul 29, 2015

@btmills

This comment has been minimized.

Copy link
Member

btmills commented Jul 29, 2015

Since the pattern key is "external" code*, my first reaction is that we should be ignoring that by default, no option necessary. Thoughts?

*If it comes from a response, then it's truly external. If it comes from an object created elsewhere, camelcase will catch the issue then. Either way, the local variable is what matters.

@willrstern

This comment has been minimized.

Copy link
Author

willrstern commented Jul 29, 2015

Sorry, I meant to say "request" not "response".
In this use case, I'm destructuring a POST request query - so as to only have camelCased locals.

I can do it without destructuring:
const category = query.category_id;
just not with:
const { category_id: category } = query;

@btmills

This comment has been minimized.

Copy link
Member

btmills commented Jul 29, 2015

Thanks for the extra context.

/* eslint camelcase: 2 */
var category = query.category_id;

The above is valid per the demo, so I'm even more convinced now that its destructuring equivalent should also be considered valid.

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Jul 29, 2015

I think this should be covered by the properties option, shouldn't it?
http://eslint.org/docs/rules/camelcase#options

@willrstern

This comment has been minimized.

Copy link
Author

willrstern commented Jul 29, 2015

The properties option would probably cover it, but it's really covering up the fact that parsing isn't distinguishing between destructuring-renaming from object-property-naming.

Adding properties would also stop camelCasing checks on all other properties throughout the project.

here's a more simple use-case:

import somemodule from "somemodule";

const { some_value: someValue } = somemodule; //errors though no underscore_spaced var was set
const someValue = somemodule.some_value; //works

.eslintrc

{
  "ecmaFeatures": {
    "destructuring": true,
    "modules": true,
  },

  "env": {
    "es6": true
  },
}
@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Jul 29, 2015

Hmm, yeah, we probably need to distinguish between MemberExpression and Property nodes rather than treating them the same.

@nzakas nzakas added enhancement rule accepted and removed triage labels Jul 29, 2015

alberto added a commit that referenced this issue Jan 7, 2016

@alberto alberto closed this in 186e8f0 Jan 8, 2016

nzakas added a commit that referenced this issue Jan 8, 2016

Merge pull request #4879 from eslint/issue3185
Update: Ignore camelcase in object destructuring (fixes #3185)
@FunkMonkey

This comment has been minimized.

Copy link

FunkMonkey commented Jun 3, 2016

This still seems to be an issue when destructuring imports, f. ex.:

import { foo_bar } from 'foo';

It is especially problematic as the user has no control over the naming in external libraries.

@alberto

This comment has been minimized.

Copy link
Member

alberto commented Jun 4, 2016

@FunkMonkey can you open a new issue following our guidelines, please?

@mathieumg

This comment has been minimized.

Copy link
Contributor

mathieumg commented Jul 3, 2016

I don't see the new issue linked here, but @FunkMonkey couldn't you do:

import { foo_bar as fooBar } from 'foo';
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.