Turn off import/no-absolute-path

[HoraceShmorace]

What version of this package are you using?
14.3.1

What problem do you want to solve?
This 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.

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 20 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 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

[HoraceShmorace]

I'll move this to the eslint-config-standard repo.

[mightyiam]

Thank you, @HoraceShmorace. Actually, this is the repository where rules are discussed.

This seems like it would be a popular enough use case to consider disabling this rule. I personally would not like to go through that documentation. But I would like the issue confirmed.

[75lb]

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, the 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.

[feross]

I agree that this is a bit prescriptive, but this doesn't seem like a common issue so it seems like a perfect use case for using a disable comment as explained here: https://standardjs.com/#how-do-i-disable-a-rule

How many others have run into this issue?

[feross]

I just realized that this rule is applying for browser imports too. Given that, I feel more strongly that this should be disabled now. We wouldn't want to prevent referring to a module file by absolute paths. That's totally fine in a browser context.

[audinue]

I just realized that this rule is applying for browser imports too. Given that, I feel more strongly that this should be disabled now. We wouldn't want to prevent referring to a module file by absolute paths. That's totally fine in a browser context.

What about an option to choose a context instead of disabling this rule completely?

This rule maybe helpful in Node.js context but certainly not in browser context.

Node.js allows the import of modules using an absolute path such as /home/xyz/file.js. That is a bad practice as it ties the code using it to your computer, and therefore makes it unusable in packages distributed on npm for instance.

From: https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-absolute-path.md

[feross]

What about an option to choose a context instead of disabling this rule completely?

Reasonable suggestion, but we don't want to add options like this to standard. Having to specify if your file is meant for Node vs. Browser is not in the sprit of standard. We want standard to get out of the user's way.

[LinusU]

@AbducteeZero you comment doesn't add anything of value at all, and instead just insults the people working on this project. Clearly there was grounds for adding the rule when it was added, and now more information have come to light and it it seems like removing it is the best path forward....

[obonyojimmy]

i think this is a valid issue affecting lots of devels and needs to be resolved . for this reason i think ill migrate off standard

[derek90]

What about adding some config, where you can specify to skip this rule for a specific path tamplate, like '/opt/**'. That way, you can keep that rule for other cases where you are able to change the absolute path for a relative one