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

eslint-plugin-node/no-deprecated-api thinks one of my webpack aliases is a deprecated node library #1082

Closed
dyegolara opened this issue Feb 28, 2018 · 2 comments

Comments

@dyegolara
Copy link

commented Feb 28, 2018

I have this in my webpack config:

alias: {
      utils: path.resolve(__dirname, 'src/utils/'),
      api: path.resolve(__dirname, 'src/api/'),
      app: path.resolve(__dirname, 'src/app/'),
      actions: path.resolve(__dirname, 'src/actions/'),
      stores: path.resolve(__dirname, 'src/stores/'),
      shared: path.resolve(__dirname, 'src/shared/'),
      constants: path.resolve(__dirname, 'src/constants/')
    }

and I am importing some of my declared constants like this in several files:

import { ADMIN_ROLE_KEY, EMPLOYEE_ROLE_KEY, EVALUATOR_ROLE_KEY } from 'constants'

The problem is I'm getting this warning:

'constants' module was deprecated since v6.3. Use 'constants' property of each module instead. (node/no-deprecated-api)

This started happening today since I updated to v11.0.0 (and I noticed it because the tests in my CI always run the latest version of standard). I know I can disable the rule on each line but I wonder if is it there a more clever way to do it.

(I know this is not an issue but more like a help wanted)
Thanks in advance 🙂.

@stale

This comment has been minimized.

Copy link

commented May 30, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale label May 30, 2018

@LinusU

This comment has been minimized.

Copy link
Member

commented May 30, 2018

I personally wouldn't recommend using aliases that way, since you might conflict with some other built-in module. Might not be the answer you want to hear but I've personally found that aliases introduce more problems than they solve...

Making ESLint aware of webpack-configuration is probably something that will never happen, although you can always open an issue with them if you want this to happen. If support lands in ESLint it would trickle down to standard as well.

@LinusU LinusU closed this May 30, 2018

@lock lock bot locked as resolved and limited conversation to collaborators Aug 28, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
2 participants
You can’t perform that action at this time.