Enable configuration file and webpack config file

[tabazevedo]

I suppose this PR is sort of to standardise the way we handle configuration.

I implemented the rc module which is a node standard for supplying configuration to applications. It reads a variety of paths and looks for the config file. Not going into too many specifics, you pretty much put a .archrc file in your application root or config folder and it'll pick it up.

I clarified the inheritance a little bit. We're following the priority as discussed previously of server options > env variables > defaults. Opening a PR soon on the CLI to potentially make it pass in options to arch-server instead of setting env variables.

Example configuration

If I wanted to overwrite my app port and serve my assets from a different folder:

{
  "port": 1337,
  "public": "doge",
  "some": {
    "nested": {
      "path": {
        "blah": true
      }
    }
  }
}

Webpack Configuration

There is now support for a webpack config in the app root directory. This will be a minimal config which is merged into the arch webpack config.

Note: You should not really import things like style files in your components - reason being the Arch server will choke when it hits a require 'style.sass'. Assets should be a seperate concern from webpack, we recommend a task runner like gulp. Open to suggestions as to a good pattern for this though.

Related Discussions:

https://github.com/arch-js/arch/issues/21 https://github.com/arch-js/arch/issues/82 https://github.com/arch-js/arch/pull/84

[chrisvfritz]

@tabazevedo I see that this answers the question I just asked in the other issue. #89 :-)

[chrisvfritz]

As I mentioned in #89, any chance for lson over json for the config? I think even for those who are writing in Babel, it should be pretty easy to figure out the syntax (I think it's even easier to pick up than yaml). A lot of projects are starting to use cson for config files, even though there's no CoffeeScript in the project, so there's precedence, if that matters.

[chrisvfritz]

Regarding:

Note: You should not really import things like style files in your components - reason being the Arch server will choke when it hits a require 'style.sass'. Assets should be a separate concern from webpack, we recommend a task runner like gulp. Open to suggestions as to a good pattern for this though.

We can have Webpack loaders compile styles for us while keeping them a separate concern (i.e. without allowing those to be included in JavaScript). For that, we'd simply use preprocessor loaders and the css-loader, but not the style-loader.

[tabazevedo]

.archrc should now support JSON, CSON and LSON.

[chrisvfritz]

:smiley:

[tabazevedo]

@chrisvfritz happy supporting LSON. Dropped support for INI syntax because who uses that anyway. Not sure I follow what you mean with the asset stuff. Happy for you to spike out a demo and I can take a look at that, but I still feel like it shouldn't be a concern of Arch.

[charypar]

Can we please move the config into a non-dotfile, dotfiles are user preferences, not project configurations. Have you considered making the file just a javascript module? Reason being you can write it in whatever the build step supports and generate some of it with code if you're so inclined (like read ENV vars, etc.).

I am still not convinced about surfacing Webpack configuration. We're opening ourselves up to all sorts of migration issues once we decide to switch to JSPM or something...

[tabazevedo]

@charypar I considered making it a module (I actually really like the way webpack does its config). That may be the right way to go, but at the same time we have things like babel, nvm and eslint which use .babelrc, .nvmrc and .eslintrc for folder/project-specific configuration. Dotfiles are just configuration files, for whatever that may be. Not sure what the right way to go with it is.

I do agree on the webpack config stuff, but this pull request is more about making what we have right now more accessible to the user.

[charypar]

Yes, but all of those things are tools. What you put in those files are user preferences. You commit them sometimes so that everyone on the team has the same setup, but there is good reason why people share their dotfiles. You'd never share your Arch config file, cause it's just app specific and there's also no reason to override the config set in the app on a higher level (like your home folder). This isn't a case for a dotfile.

[chrisvfritz]

@tabazevedo Happy to code up a demo to show you what I mean. The way I'm thinking about it, we could get around exposing any webpack configuration (as @charypar would like to avoid) with a few lines of configuration to cover 90+% of what people might want to access the webpack config to do.

Weighing in on the dotfile debate, it doesn't make a big difference to me, but I think .babelrc etc are different in that they aren't for project configuration, but configuration of a specific tool within the context of a project (edit: which it looks like @charypar just pointed out while I was typing this!). Then again, Meteor keeps all its configuration in a .meteor folder, so there's precedent. Meteor is the only framework I know of that does this however.

[chrisvfritz]

@tabazevedo Finally found some time this morning to hack on this and am now better understanding the problems involved when trying to do server-side rendering and requiring css. It looks like we should be able to work around it though. I'm willing to write up a pull request for basic CSS preprocessor support, though I do have a few questions:

1. Most importantly, as long as it's a low-maintenance solution, is this something Arch would be willing to integrate?
2. If the answer to 1 is, "No, we really don't want this being part of Arch," then is there plugin system planned for Arch where this could be made possible?
3. If the answer to 1 is, "Yes," would you prefer to have a system where we're requiring css from js/ls (more ideal for component work, but also more tightly coupled to webpack), or one where we're just building scss/etc to a single css file, completely separate from our js/ls (less ideal, but could be completely decoupled from webpack by having gulp coordinate everything)?