Consider making standard a peerDependency so the version is controllable by the user

[timoxley]

As above.

[timoxley]

Also may want to consider making standard a peerDependency so the version is controllable by the user? This does make the cli install process a little more clunky, but I don't think it's prohibitively bad.

[Flet]

Published as standardx@2.0.0

[Flet]

I'd like to hear some folks thoughts on switching to a peer dependency on standard.

It adds a lot of flexibility, but its also a bit more clunky as you mentioned.

[Flet]

Updated/hijacked the issue title to "consider making standard a peerDependency so the version is controllable by the user" :)

[Flet]

any @standard/folks have thoughts?

[LinusU]

I think that I think that the most convenient would be if standardx mirrored the versions that standard was published under. That being said, that might not be worth the extra work in setting it up and maintaining it.

Although, just publishing three versions (9.0.0, 10.0.0, and 11.0.0) that all have a caret dependency on the same major (.0.0) would allow the user to select specific version if they want to, but still be able to add this package with just one npm install command.

I don’t have any strong feelings though, this is just my 2¢

[ungoldman]

Agree with @LinusU. It would be nice to install a specific version of standardx that matches a version of standard and avoid the many issues associated with peer dependencies altogether.

Edit: In practice this might not be possible, since standardx may have its own issues and patches that don't correspond to standard at all.

[timoxley]

Agreed, that seems like a good middle ground

[brodybits]

I just discovered this nice repo with this issue, would favor the following alternatives:

• update standardx to just use standard-engine
• update standardx to use eslint with eslint-plugin-standard, etc.