Consider "un-vendoring" packages

[harrysarson]

#446 has got me wondering whether the pro/con balance has shifted since we decided to vendor all our elm dependencies. Opening this issue to discuss whether we can un-vendor them again.

[harrysarson]

Context:

Both these lint rules come from package code we have inlined due to complications arising from installing extra packages. Maybe now that we use elm-json and the whole dependency resolving thing is much more solid now we could revisit these deps and see if we can un-inline them.

Originally posted by @harrysarson in #446 (comment)

I have a very similar situation in elm-review where I also generate parts of the code to be run and where I have vendored some dependencies to avoid complications. I have prefixed/moved those to a Vendor folder and ignored all of my rules for that folder.

Originally posted by @jfmengels in #446 (comment)

[jfmengels]

I vendorize the code in elm-review for 2 reasons:

1. To avoid naming conflicts where a user has a module with the same name as a module from the dependency. I prefix the module name with something unlikely to have a conflict, like Vendor.Elm.Review.SomeModuleName.

2. To avoid dependency conflicts: If elm-review depends on foo/bar v1 and the user also depends on foo/bar but v2, then the compiler will complain and the tool will be unusable for them. By vendorizing/inlining, that problem goes away and the user is free to use whatever they want.

I imagine these problems could still appear in elm-test, so I think that vendoring is still a good idea, until at least Elm allows for multiple major versions for dependencies.

[harrysarson]

Makes sense! Both (1) and (2) would be really annoying errors too.

Looks like we need to keep the vendored code around for now!