Is it currently possible to get idempotent builds with ember-cli and its dependencies (node,bower). If so how are people achieving this?
The craziness of the node dependency tree seems to make it implausible to check everything into source, not to mention compiled dependencies are different between our development environment and production since we can’t currently get ember-cli to work well on docker/containers.
➜ app git:(master) du -sh node_modules
➜ app git:(master) du -sh bower_components
@stefan sorry for the lack of clarity. I mean the entire build process for an ember-cli application, so a fresh checkout on a new developers machine or on our CI that includes a npm install and bower install step. When this occurs at any point in time X after the code is committed we have no guarantee of what is actually going to happen with the default setup.
This seems like a highly critical aspect of developing Ember applications (and any other npm dependent apps) in organizations that have something to lose(money, data,etc), so I am thinking some in this community have already solved this problem or at least duct taped it for the time being.
From my research the possible set of things people are doing:
Checking in their node_modules directory.
This seems insane to me (size, compiled binaries, doesn’t actually give idempotency b/c of weirdness w/ npm rebuild)
You and others say this is broken. I don’t fully understand the tradeoffs or how broken it is and in what way.
I was speaking with @mixonic about this at last nights NYC meetup, and looking to lock down where this issue stands and what’s missing. My intention in starting this thread is to see if there is anyone out there in Ember-land using this stuff successfully, what are the pitfalls, etc.
I think we could probably get our app to build on CI as well, but we would do so by dropping docker features that we want to use in development and do easily for every other app we work with.
My checklist is:
Use the ‘standard’ docker tools for dev on OS X. (docker-machine, docker-compose, boot2docker, virtualbox)
Mount my application code as a volume so I can edit it on my host machine (Mac)
Ability to cache dependencies so that I dont need to redo npm/bower install build step when I only change app code.
Build in a similar timeframe to building on the host machine.
If anyone has a Dockerfile they can share that achieves this that would be awesome. The specific hurdles we have seen are around virtualbox filesystem being very slow with the number of symlinks created while running ember server, and the inability to mount our application code because of the inclusion of node_modules and bower_components within the project path. File system events also do not get triggered within the container so we need to use --watcher=polling but that seems OK to me.
@stefan the purpose of my post is to seek the perspective of the community on how these issues are being resolved now in their organization in the context of their ember-cli and Ember.js investments.
I can’t imagine for example Square is OK with deploying an Ember app and not knowing whether what they build in their CI for deployment is the same as what their developers tested and intended to deploy.
Jake doesn’t realize, but because he already had RSVP installed, he did not get the one specified in shrinkwrap.json
pain and bugs etc etc
Now, it is possible (assuming shrinkwrap) has no other bugs, and tests and extremely good for CI to benefit from shrinkwrap.json unfortunately it is bonkers that developers can troll themselves and each others with the existence of shinkwrap.json. I believe it must become the canonical truth.
So something we have done to slowly improve the npm dep issues, is use ember-cli-dependency-checker to assert that when you boot your app, that the dependencies you have are actually the ones specified in package.json. I believe we could extend this checker, to prefer shrinkwrap.json for its source of truth. This may be how we mitigate most of the shrinkwrap pains i have had in the past.