Split core logic into separate package to be used outside of ember

[herbrandson]

I love the way this package works inside of ember cli. I would really like to have similar functionality in another non-ember application (a simple node.js server project). I've only quickly scanned the code here, but it seems like it wouldn't be too hard to split this into two separate npm packages. One being a generic package that does the version checking in an ember agnostic way and the second still being called ember-cli-dependency-checker which would consume the first. I envision the first package returning some sort of json structure that describes what packages are missing and/or need updating.

Do you think this could be done without too much pain and suffering? If you had the time and interest to create such a package, I may be willing to trade you for my left kidney. If not, I would be willing to attempt using your code to create such a package (assuming you think it's do-able and I have your blessing). However, I do have a looming deadline at the moment so it would be a few weeks before I could look into it.

[quaertym]

:+1: I have a plan to work on an ember-agnostic dependency checker. However it is not clear how to make it work without ember-cli's build process and addon architecture. I think dependency-checker perfectly fitted ember/ember-cli workflow. It won't work seamlessly as in ember's case for other projects since it will require the consumer of that package do some work based on his build process. I am giving some thought to improve that experience for non-ember projects.

[herbrandson]

Fantastic!

Can you tell me more about the problems you're running into WRT non-ember projects? I was envisioning it needing a package.json and/or bower.json file and a node_modules and/or bower_components directory and being able to do it's magic from there. However, I obviously haven't through the implementation details to the degree that you have. What else would the consumer need to provide?

If such a package could be created, I could see there being grunt, gulp, etc. wrappers that would allow the functionality to be available to all sorts of custom build processes. For that matter, any application could actually verify itself as part of the startup process and exit if the needed dependencies weren't present. Just thinking out loud about all the cool possibilities... :)

[quaertym]

A standalone package requires user to integrate dependency-checker with user's broccoli, grunt or gulp setup. The benefit of ember & ember-cli conventions is that it allows to build tools and higher abstractions as in the case of dependency-checker. I am interested in extracting dependency-checking part of this library and use it in this addon but I am not interested in building grunt or gulp plugins.

I will close this issue now and reopen it when I have more concrete thoughts and work.

[kellyselden]

I wonder if it might be possible to avoid build tools in the abstraction. Something like this for a node rest server:

"scripts": {
  "start": "node check-dependencies.js && node server.js"
}

Just to solve the issue of someone adding/updating a package in the node server, and not all devs noticing to do an npm install.

[quaertym]

How do you get the check-dependencies.js?

[kellyselden]

It could be the "bin" file of the hypothetical new library. It wouldn't be imported into a consuming app, but run via command line before running your app.