Is there anything written anywhere about how to use Ember in module mode without Ember-CLI or ES6? This could potentially help with integrating it with AMD directly. (I mean, the CLI stack uses AMD/require under the covers, right?)
Sample code to precompile headers from a list of files in Node would also be helpful.
Here are our real-world constraints:
* Many organizations, separately managed, all contributing code to the corporate servers.
* All builds are the directories of Visual Studio projects which are loaded from source control and the .csproj then built.
* No access to the corporate build server to install anything project-specific - this would rapidly get out of control.
* The project can include executables used to build other things. For instance, our project has a build area with a build.bat, a node.exe and r.js to uglify our client code. We have custom build step that invokes our build .bat.
* Builds are self-contained. The build server does not do fetches from any module systems like NuGet, NPM, etc. All third-party libraries that are to be used in a build must be checked into source control to be used from there before the build is submitted.
* Nothing gets onto a corporate dev, staging, or production except from the deployment output of such a build.
* All pages must have corporate headers and footers, which can pretty much add anything to your page without notification.
We currently compile our templates on-the-fly in the browser, so we're still completely edit/clear-cache/reload in development, but I'm not particularly religious about that. I'd love an environment that does compile on the fly for development and precompile for release. I've made a few stabs in that direction but ran into problems. A working example would help. We could incorporate that into our build .bat as well.
Whenever we depend on a global, the next version of the headers checked in can introduce something that breaks our page.The less we reference anything global, the less vulnerable we are to whatever the corporate headers dragged in at runtime, so we lean very heavily toward building a closed system around modules we've loaded via AMD defines and requires.
We could use Ember-CLI but it would involve a few pain points. We'd have to build the client on development servers and check the baked result into the server project, which is a security risk. Checking in files with dates in their names makes for a lot of source control churn. We'd also have to induce Ember-CLI to generate the index.cshtml that server-side includes the corporate headers and footers at moment of access rather than index.htm and then do the right things with reference paths.We'd have to rewrite our entire project to use ES6 import/export. We'd be living in a fools paradise when developing in Node at port 4000, because we wouldn't be choking on the corporate headers. (As it is, right now we have local IIS configured with ARR to behave as exactly as possible like the corporate servers even when debugging fresh code. I don't like surprises.)
None of this is completely insurmountable, but if we had just a little guidance to adapt what we have to work with the latest stuff without taking all that on, that'd be grand.