Closed kyeotic closed 8 years ago
Hey @tyrsius I could update, but as of 3.4.0
, this package will use the standard bellow your project's node_modules
Ah, that's probably why atom starts throwing errors when i npm prune --production
for integration tests
Related issue: https://github.com/feross/standard/issues/574
@ricardofbarros Any reason not to keep the standard
dep reasonably up-to-date?
Hey @feross, I wanted to move out from having standard, semistandard, etc. as dependencies of this package, because some times the windows users have some problems installing this package because of the path size. I think the issue of atom package's having a long path is already widespread and it's being discussed actively.
My idea was to slowly move to the approach of using the projects node_modules standard bin or if there isn't a node_modules directory check the user's PATH for the standard, semistandard, etc.
Sounds like a reasonable approach. I think it would be better to remove the standard
dep entirely though, so it doesn't revert back to standard v5 when users don't have a local copy installed.
I believe the windows long path issues has been fixed some time ago with newer npm releases. I like the idea to prefer my local node modules.
But remove it entirely? I don't think that's a good idea, since we have to install standardjs global to be able use it for non nodejs javascript code, right?
I've updated all linter and custom parsers deps on the latest release.
Standard is looking to move to version 8 soon. This package is still on
5.4.1
.Whats the timeline for updating this package to keep pace with standard?