standard / eslint-config-standard

ESLint Config for JavaScript Standard Style

Home Page:https://standardjs.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Turn off import/no-absolute-path

HoraceShmorace opened this issue · comments

What version of this package are you using?
14.1.0

What problem do you want to solve?
The import/no-absolute-path rule can't be used with projects that involve AWS Lambda Functions that reference custom code in Lambda Layers. Layer code MUST be imported relative to the root ('/opt/[layer path]'), which is an absolute path. See https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html.

I've finally gotten our teams to use Standard for almost every project, zero customizations. Now I'm getting pushback because of this issue. We could disable that rule inline, but if you have to turn a rule off 30 times, then is it a worthwhile rule?

I'm sure someone will suggest that we just "figure out" the relative path (even though AWS's official docs say to use the absolute path), but then we'll be making assumptions about the current and (more importantly) future state of a filesystem we have no control over and that could likely change, breaking our services.

What do you think is the correct solution to this problem?
Turn this rule off. If it can't be a best practice everywhere, then it's not worthwhile.

Are you willing to submit a pull request to implement this change?
Sure

Though it undermines the philosophy of JavaScript Standard Style (and thus its validity in the eyes of our engineers), I'll just use standardx and override that rule.

Please re-open, I too would prefer this rule is removed from standard. What is the problem with absolute paths anyway? They are valid.

In my web projects, this rule prevents me importing npm-installed ES modules like this:

import something from '/node_modules/something/index.mjs'

Instead, this rule forces me to use messy and brittle relative paths (which need fixing if the source file changes directory):

import something from '../../../../../node_modules/something/index.mjs'

It is common for absolute paths to be used in web projects (for example <link rel="stylesheet" href="/global.css">), I don't see the logic for blocking their use in import statements.

Problem is that in many cases an absolute path is likely a mistakenly left out “.”, but in the cases of eg. Lambda it would make sense to have a lambda specific extension of standard, which can be easily achieved by using the eslint rules directly, see eg: https://github.com/voxpelli/eslint-config

in many cases an absolute path is likely a mistakenly left out “.”

but in many cases it is not... seems daft to ban absolute imports just in case a relative path user made a typo..

@75lb instead of

import something from '../../../../../node_modules/something/index.mjs'

why aren't you doing

import something from 'something/index.mjs'

🤔

Because that wouldn't work in the browser - the '<package>/<file>' module ID format is a Node.js convention. Third-party bundlers also support this format with a plugin.

In the browser, module-name must be a relative or absolute path.