@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)
- Using shrinkwrap
- You and others say this is broken. I don’t fully understand the tradeoffs or how broken it is and in what way.
- Some shrinkwrap replacement
- shrinkwrap + some shrinkwrap enhancement library
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.