Use consistent-env package about atom-linter HOT 7 CLOSED

Asked him in #packages of slack, see https://atomio.slack.com/archives/packages/p1448052728000048

from atom-linter.

Bringing that conversation over here, since there is a limit to that history:

@steelbrain:

Ping @joefitzgerald
​[12:52] I am interested in using your environment package in linter providers, but I have a question
​[12:53] For almost all the linter providers, the module that actually spawns the process is atom-linter, it's an npm module that these apm modules depend on. The fact that you are exporting a service instead of setting a global limits it's usage in atom-linter, to use that all the apm packages need to consume that service and then pass it on to atom-linter::exec, it could've been simplified if you were, say setting a global, it would be accessible everywhere and would simplify the implementation

@joefitzgerald:

maybe you should use an executor service
​[1:22] that depends on environment

from atom-linter.

@Arcanemagus Thank you for bringing this up, I had almost forgotten about it :)

@joefitzgerald I would love to create a service for that, but we would then have to publish this package on apm instead of npm and all packages would have to use it via atom-package-deps instead of directly. Also it goes against the concept of packages IMO, 'cause the user will see it in their list and will be given options to uninstall it

from atom-linter.

@steelbrain this package has been proposed to fix this issue in a few of the linter-* packages by @lexicalunit: https://www.npmjs.com/package/fix-path

Maybe we could use it if we can't work around the service requirement of environment?

from atom-linter.

I am very much in favor of that module you linked to, but the fact that it alters a global when it could return a value would mean that when it's used by multiple packages, it would add duplicate entries. Other than that, it's using hard-coded values opposed to @joefitzgerald's package that finds out the paths by actually executing it, which is a better way IMO

from atom-linter.

As discussed over in AtomLinter/linter-shellcheck#35, this really is something that should be fixed on the Atom side in the end, although we should probably work around this shortcoming temporarily till it lands on stable. It looks like the issue to follow for getting this into Atom: atom/atom#4126

from atom-linter.

I've created a new consistent-path package that should make things easier for us, it's results are isolated and it's an npm package. It also has internal caching as opposed to fix-path by sindre. Thanks for the idea @lexicalunit

from atom-linter.