Write app.config spec #105

Closed
paulirish opened this Issue Jun 25, 2012 · 21 comments

Comments

Projects
None yet
9 participants
Member

paulirish commented Jun 25, 2012

It's become more clear we need a config file that declares paths and operations, so that there is better tool interoperability and things like changing the paths and locations of my app folders is easy.

Previous art:

@borismus We talked about this a little bit, did you have extra thoughts we could add here?

  1. First step is capturing what information should be in this tool-agnostic app config manifest
  2. Second step is picking a format.
    • js works really well for gruntfile, whereas something declarative like yaml or json5 might be pleasant too.
  3. Third, implementation. boom
Owner

addyosmani commented Jul 1, 2012

@paulirish As we have an ongoing e-mail thread about bower and RequireJS paths, just thought I would confirm: does #98 tie into this?

Member

paulirish commented Jul 18, 2012

As discussed today, yes it does. :)

Owner

sindresorhus commented Aug 13, 2012

I would vote for it being .js/.coffee. This makes it possible to contain non-standardized config stuff and to eg. set the js/ path with code, like if it's differs between devs.

I guess the thinking is that the Gruntfile will just import what it needs from the config file?

Owner

addyosmani commented Aug 13, 2012

@sindresorhus I'd be down with that.

Would someone like to propose what this config file might look like so we can discuss structure/what else needs to go in it?

Ties into #98

Contributor

commadelimited commented Aug 13, 2012

My only comment here would be to use JSON. Yeoman is a web development toolset. Everyone using it will be familiar with JSON whereas not everyone has familiarity with YAML or HAML or whatever you kids are calling it these days. Plus the Gruntfile is already JSON.

Owner

addyosmani commented Aug 13, 2012

We're still looking for someone to take ownership of this ticket / centralized config. Any takers? :)

clexit referenced this issue Aug 17, 2012

Closed

Package managers #222

clexit commented Aug 19, 2012

I'll start from the easiest question about format. My vote is for JSON too. Why need to use something else if everything is written in JavaScript already?

Now, what should be in app.config and how it might work (we can cross out things that may seem like overkill):

  • If yeoman init is called in a non-empty directory and it can't find the Gruntfile but it found some files except for app.config in the directory, it should ask user where he/she needs to initialize Yeoman for an existing project or to create a new one.
  • If user says it's an existing project:
    • Yeoman should look for an app.config and if it finds it, ask the user whether Yeoman should use it for the initialization or not.
    • If there is no app.config in the directory Yeoman should look for a global yeoman.config (somewhere in a user's home dir) and ask the same question.
      • If user says 'no' or there are no configuration files at all, Yeoman should scan subdirectories and look for .js/.coffee files, .css/.less/.sass/.scss files and images. After that it should ask user whether it found the right directories or not.
      • If user says 'no', prompt where the user can set the paths manually appears. A notice that the paths may be set later by changing app.config prints in a console (so user can skip everything and change paths in an old-school way).
    • Yeoman assumes that the app/ directory is a directory that contains js and css folders but it should ask again.
    • Yeoman asks where the build directory should be (is it connected with issue #177?)
    • Yeoman asks should it change filenames while building a project or not (blablabla.main.css). This is needed because in some companies files have a timestamp '?' tail added automatically when deploying on production servers, thus they don't need this renaming mechanism.
    • If it finds main.css file it should ask user for an output css file name. If there is no main.css then Yeoman assumes he can create one and use it for concatenation and minification.
    • It should ask where should it put usemin handler and whether it is needed. This file might be somewhere far away from app/ directory, and it's not not always index.html. For example, in our case it's layout.html.tpl for some of our projects.
    • (maybe a question about package manager, issue #222)
    • (something about tests?)
  • If user creates a new project:
    • Yeoman should look for an app.config and if it finds it, ask the user whether Yeoman should use it for initialization or not.
    • Yeoman should look for a global yeoman.config (somewhere in a user's home dir) if there is no app.config in the directory and ask the same question.

Thus, app.config may contain this information:

  • Directory names:
    • app/
    • JavaScript
    • CSS
    • Images
  • File names:
    • main.css
    • usemin handler
    • OPTION: whether files should be renamed or not
  • Build destination
  • (package manager?)
  • (something about tests?)

There also should (should it?) be a command to update the project according to changes in an app.config (it shouldn't erase any changes that user did in Gruntfile manually, though).

We can get rid of many questions, but there are many things that should be configurable for advanced users anyway.

Now this might not be an ideal solution but we have to start with something, so... let's discuss it.

clexit commented Aug 21, 2012

crickets

No one seems to be interested in configuration and compatibility with existing projects but anyway...

I've tried to play with this a bit and don't quite like the result. We can read app.config file, parse it and pass the JSON to a generator that was called but it means that every generator should check the configuration and handle it. Is it OK? Any ideas/suggestions?

Here's the code.

Owner

addyosmani commented Aug 21, 2012

@clexit Work on a centralized config was started this weekend by @mklabs. Unfortunately we have a number of issues open related to config at the moment and comments for them aren't cascading. @mklabs would you like to give a brief overview of the work you've been doing here in case it helps with the above?

Contributor

mklabs commented Aug 21, 2012

duplication of effort with f6c7d3f but thanks @clexit it's nice.

Basically, it's more or less the same, each generator have access to the grunt config with self.config, and should use the path values that are here (the role of your appconfig property) each time they need to write something that is likely dependent on one of the paths that are defined in this config file.

Contributor

mklabs commented Aug 21, 2012

There is two main points to handle regarding this path issue, generators and the build process.

The Gruntfile and all the paths that are defined here (app/, app/scripts, app/styles and so on) will need to be dynamically resolved, or simply reflect the paths values with the app generator when it generates the gruntfile, most likely based on a gruntfile undescore template.

clexit commented Aug 22, 2012

Oh, great. Yeoman really needs this for the release.

I'll delete my branch and ask a few questions:

  • Are we going to rename app/ and vendor? (they are hardcoded now but existing projects may use other names for this kind of folders)
  • What about other options? Will they use ./config/some-other-files.js?

Can I help with this or compatibility issue?

Contributor

mklabs commented Aug 22, 2012

Interesting questions:

Are we going to rename app/ and vendor? (they are hardcoded now but existing projects may use other names for this kind of folders)

mklabs/yeoman@73354a3#diff-2 is what I though about in terms of directory to handle, didn't thought about the vendor folder, but it might make sense.

What about other options? Will they use ./config/some-other-files.js?

I can't tell, and haven't a strong opinion about it. An app.config file next to the Gruntfile would work too (assuming it's just JSON). I went with ./config/paths.js rightly because I'm starting to think that the Gruntfile and all the config are a bit heavy, and that we would gain to split this up in multiple files. The introduction of a ./config/ directory would help.

I don't know what are the next steps, I guess this needs further discussion to decide exactly what we need / want.

clexit commented Aug 23, 2012

I looked through many our old-and-huge projects that cannot be changed so Yeoman cannot be used there unless it has some options and missing only a vendor option so far.
usemin-handler is also needed but it can be set in the Gruntfile (it didn't work with absolute paths though, but at least it can be changed).

It may be a good idea to add some other options later like default answers on Yeoman questions or predefined CSS-preprocessors, test frameworks and so on, but paths will be absolutely enough for v1, and if Yeoman is going to be a universal tool that can be used anywhere by anyone it should be fully configurable and customizable which means a special place for configs will be needed (./config/?).

Maybe @veged has something to add?

veged commented Aug 23, 2012

As I proposed for grunt https://github.com/cowboy/grunt/issues/110#issuecomment-4990754 I can recommend .yeoman/config.js. So there is few points:

  • Configs in programming language is more expressive than some JSON object which need to be "interpreted" by some smart code. If you have full features programming language you still have ability to write simple things simple and get possibility to express complex things. Actually it's a kind of holly war, about configs-as-data and configs-as-program -- so I'm definitely at the second side ;-) we use that concept in many our projects and have never regretted.
  • Separate .yeoman/ directory for all stuff provide nice storage for any other service files, such as some depends or modules. Thats approach already well recommended in practice by tools like git, svn and so on.
Owner

sindresorhus commented Aug 23, 2012

@mklabs What do you imagine being in the .config/ folder besides path.js?

As a user I would prefer one file where I can specify all my configuration, like: config.{js,coffee}

I'm starting to think that the Gruntfile and all the config are a bit heavy, and that we would gain to split this up in multiple files

How would we split up the Gruntfile?

Contributor

mklabs commented Aug 24, 2012

@sindresorhus I'm not sure anymore about that.. I'll probably take a step back, leave off the global yeoman config file system, and just fill in a grunt.config('paths') config that we just use throughout the Gruntfile via <config:paths> directives and in our generators using the this.config.paths Hash.

To split up the Gruntfile, I was thinking of relying on some require('./config/*.js') to populate the Gruntfile, or if it's just json using <json:...> directives. It fails with the idea of having a ./config/build.js (or ./config/dev.js) where the config file should update multiple config tasks. There's definitely some way to do it, but would be a bit different than the typical grunt.initConfig(): Typically, we would require('') any file within the ./config/ directory, pass them the reference to grunt and setup the config using grunt.config('watch', { ... config for the watch stuff ... }) etc.

shairez commented Feb 5, 2013

Is there any risk with using solutions like #595 for "app" and such in the meantime?

I am actually using a similar approach on all of my projects, take a look: https://github.com/toi-agency/generator-restangular/blob/master/AppConfig.json

I think that is a good idea because we can use multiple generators in our projects which will look for the config file and generate the given scaffold in the given folder.

What do you guys think about that? @paulirish @sindresorhus

Owner

addyosmani commented Jan 9, 2014

We now track configuration information in .yo-rc. It's the responsibility of each generator to use this feature how it sees best and we'll be improving our docs around this in the near future.

addyosmani closed this Jan 9, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment