au command for bundling app outside of root folder

[threeaccents]

I'm submitting a feature request

• Library Version: 0.18.0
• Operating System: OSX 10.x
• Node Version: 6.2.2
• NPM Version: 3.9.5
• Browser: all
• Language: all

Current behavior: When running au build all the CLI does is bundle all the assets and put them in the scripts folder. Even if we pass in the env flag with a prod value.

Expected/desired behavior: I would like for the production build command to create a dist folder that has all the assets bundled up along with the index.html file and other file needed to run the application.

What is the motivation / use case for changing the behavior? Deployment. If this was the behavior then deploying an Aurelia app would be very simple specially with services like Firebase that just expect you to pass in your production folder or something like Netlify where they ask what command to run and what the production folder will be.

[pfurini]

Another popular use case nowadays is for automated Docker deployment.. This feature is a must for production use, I'm trying to migrate my app from jspm to the CLI, and this is the first showstopper along the way..

[AStoker]

You could modify your build commands such that it takes the output of the scripts folder, and your index.html, and copies them over to an export folder (or named whatever you want). The CLI uses Gulp for it's tasks, so there's no reason (that I can think of) why you shouldn't be able to do this. Yes, it's not built into the CLI, but you can still achieve the same result yourself.

[pfurini]

I was under the impression that one of the aurelia-cli main goals is to reduce the time spent for beginners to get started, and align to aurelia's just sensible defaults policy.. The current output of build command, and the overall structure of the generated sources, are not suitable for production use, and yes, that's my opinion but based on months working on dev-ops best practices.

For example, they put the index.html and favicon.ico files at the root, and that's ok if they are copied in a dist folder upon building.. Well, what if I have a real production ready web site, that has browserconfig, manifests, robots, etc.? Putting them all in the root, alongside with package.json and other project stuff is rather messy IMHO..

So yes, the DIY principle is always valid, and TBH I never use a CLI in production code (I prefer 100% control over my build process), but given that the CLI should be beneficial for beginners/less experienced devs, this issue is still relevant..

[AStoker]

Not denying that, if I came across that way, I'm sorry.
Remember, the CLI is still in beta, so there are many features that are still not added. I was simply trying to help you get past a roadblock, as it seemed that you couldn't get past the issue.
We currently have our production setup such that wwwroot and src are siblings. Inside wwwroot we have the index.html and the compiled output of the src. That way we only have to publish the wwwroot folder, and it contains everything (and nothing else) we need.
I believe the ASP.Net setup with the CLI imitates the same setup... Could be wrong though :)

[pfurini]

Sorry if I came off as a bit rude.. I appreciated your help, and I know the CLI is not production ready yet.

But having used Aurelia since the beginning, I really feel the pain of the tooling story.. I fought with the original CLI, then with the various skeletons, then with JSPM, and now I have a fairly stable setup with the latter, but with the pre-release libraries. Now I open the docs again, and see that the official loader is become RequireJS, but a couple of months ago it seemed all the love should go towards Webpack.. Easy! (having seen a couple of webpack projects, it's easier to put a camel in the eye of the needle :-P )

So.. if I decide to go down the RequireJS route (will it be last time I switch loader? who knows..) using the CLI, is there a recommended way to "plug" into the CLI apis, using it from my gulp tasks, or instructing it calling my tasks? Is there some developer (not user) docs that list the public APIs? For example, in build.ts (using typescript here) there is an import {build} from 'aurelia-cli';. This is the entry point for all the public APIs, or there's more?

Thank u very much for your support.. ;)

[EisenbergEffect]

@nexbit You can easily customize the cli's build process. It just uses gulp under the hood. Just go into the aurelia_project folder and you will find the tasks. Simply customize those to represent your workflow.

[pfurini]

That's half of the story.. The CLI does some heavy lifting (Bundler, PackageAnalyzer, ..), and its work is hidden under node_modules, without a proper documented API. One of the things that breaks the build is just the directory layout.. At least you should consider documenting every option in aurelia.json, even the hidden ones (like the config property under the loader node, that I discovered reading the sources). Maybe changing the dir layout works OOB and it only needs adjustments in aurelia.json..

Please consider reopening this issue, as the feature req it represents is valid IMHO, maybe just change the title that sounds too opinionated (to something like Let the user change the default directory layout)..

Thx, P.

[AStoker]

I think the reason this was closed was because it's something that can be done relatively easy in a gulp task. People have different deployment setups, so what might be a default use case for you, might not be applicable to someone else. Your request for more complete documentation on the aurelia options is valid, but not under this issue (remember that the CLI is still alpha, and docs will come over time, especially as things get solidified).

[threeaccents]

@EisenbergEffect @AStoker I also think you should consider re opening this issue. I understand that everyone has different deployment setups but I think that bundling the app into a dist folder or at least not in the root folder would benefit most aurelia-cli users.

[Kayli]

I think the reason this was closed was because it's something that can be done relatively easy in a gulp task.

Please give us an option at least to override dist path, so that reconfiguration indeed can be done relatively easy.

[th3mon]

I created dist task for my project as a gist. You're welcome :)!