Caret ranges not respected properly

[Arcanemagus]

I've been seeing several issues with caret ranges not being respected in package dependencies.

Several of the linter-* packages depend on the atom-linter package, so there are usually several instances of it installed in a particular Atom installation. The issue is that when a package with an older version of the library loads it before a package asking for a newer version loads, the older version is used instead.

For example:
linter-js-yaml had version 3.3.7 installed of atom-linter, which is perfectly fine for its asked for version of "^3.3.7". When testing linter-php which had "^3.3.9" specified in its package.json however, I was getting errors that had been fixed in 3.3.8 and checking the trace it showed that it was using the 3.3.7 from linter-js-yaml's installation.

According to semver's definiton of caret ranges a request for "^3.3.9" should be equivalent to ">=3.3.9 <4.0.0", but Atom is loading 3.3.7 which does not fall within that range.

I've been seeing this on Windows 10 x64, on Atom 1.3.0-beta6. (And older versions of each before in the past).
I think I've seen it before on Ubuntu, but can't verify that at the moment.

If this has already been reported please point me in the right direction as I could not find it.

[steelbrain]

I was debugging a problem with a guy in #linter this morning and we experienced this same issue. He was on windows too (I haven't experienced this on linux yet). He had installed the latest linter-phpcs and still had a previous version of atom-linter installed.

[maxbrunsfeld]

Atom purposefully does not allow packages to depend on other packages in any way. Atom can only load one version of a given package at a time; packages aren't like npm modules, where multiple versions can be loaded in different local scopes. It's not possible with Atom, because packages mutate global state (e.g. event handlers on DOM nodes and global variables like atom.workspace).

I'm guessing that the packages you mentioned have their own code that dynamically installs atom-linter, and this code probably installs a bunch of redundant copies of that package. This is a problem with these packages, and not something under Atom's control. I think those packages should remove that code.

We're strongly opposed to any feature where packages explicitly depend on other specific packages, because it creates an unnecessarily tight coupling between those packages that could be avoided using services. With services, another package can implement the same interface with improvements (e.g. someone could create their own linter package that provides the same service, but uses a different UI).

We have an open issue on apm, atom/apm#387, that discusses adding a new feature called 'required services' that will allow packages to specify that certain services (e.g. linter) are required in order to use the package. The plan was to have apm automatically install the most popular package that provides that service. We haven't yet started implementing that feature. If either of you are interested in giving feedback on that feature, or helping to implement it, that would be awesome!

[Arcanemagus]

This issue isn't about packages, but their dependencies. All of these Atom packages have this in their package.json:

...
  "dependencies": {
    ...
    "atom-linter": "some version specification",
    ...
  }

Let's say packageA specifies "atom-linter": "^3.3.7" and packageB specifies
"atom-linter": "^3.3.9".

If Atom loads packageA first, then packageB will be using the atom-linter loaded in packageA, even though it is below the minimum version that should be allowed.

---

The "required services" sounds great, subscribed to that issue, but package level dependency has absolutely nothing to do with this problem.

[steelbrain]

Just for clarification: linter is an atom package, atom-linter is an npm package

[maxbrunsfeld]

linter is an atom package, atom-linter is an npm package.

Oh I see. Thanks @steelbrain. Yeah, maybe this is a bug in the module-cache. It uses semver.test to test compatibility, so it should support all the standard semver features for free. Not sure what's going on.

[Arcanemagus]

I'm going to close this issue, I haven't noticed it recently. I'm not sure if that's just because it's no longer an issue, or there hasn't been a situation that exposes it, in either case though if it's still a problem later this can be re-opened or re-filed.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!