Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generators do not work properly for nested routes when indent=4 #96

Open
ralmidani opened this issue Nov 8, 2015 · 2 comments
Open

Comments

@ralmidani
Copy link

I have this addon installed, and I change generated CoffeeScript code to have an indent level of 4. When generating a route nested under another route with the command ember g route parent/child, Ember CLI appears to look for the parent route with an indent level of 2, and when it does not find it, it adds the child route unnested with an indent level of 2. The code looks something like:

Router.map ->
    @route 'parent'
  @route 'parent/child'

When using plain JavaScript and issuing the same generate command (in a test project), I get this:

Router.map(function() {
  this.route('parent', function() {
    this.route('child');
  });
});

The result of the unexpected behavior in CoffeeScript is having to modify more than just the indentation of generated code. Is there any way to remedy this? I could take a look at myself if someone guides me to the relevant file(s).

A more general question: does this addon support indentation levels other than 2 for generators?

@kimroen
Copy link
Owner

kimroen commented Dec 22, 2015

A more general question: does this addon support indentation levels other than 2 for generators?

The generated files are actual files, so the indentation in them are static. Here's models, for example. I believe this was discussed at some point in ember-cli, but it was decided that it was not worth the trouble to make it dynamic. Either way, it's an ember-cli thing, not an addon-thing.

The result of the unexpected behavior in CoffeeScript is having to modify more than just the indentation of generated code. Is there any way to remedy this?

This is a result of the way ember-cli and ember-cli-coffeescript has evolved. Previously, modifications to the router file was done by detecting sections with regex and inserting sections of code. Now, in ember-cli this is done instead by parsing the file, making a tree (AST) out of the code, making the changes and then generating the file again. This is handled completely by an addon that ember-cli uses; ember-router-generator.

Now, ember-cli-coffeescript is still doing it the old regex way, and so it is much more prone to failure. You can see the code over here.

The proper way to fix this is probably to parse the CoffeeScript somehow, make modifications to the code tree and then output a new file, but that is unfortunately beyond the scope of the kind of thing I have the time to learn and change at the moment. A different (but more temporary) way could be to take more kinds of spacing in to account in the regex.

If you want to take a shot at either one of those, I'd love that.

@kimroen
Copy link
Owner

kimroen commented Jun 5, 2016

Tried out some things with the idea of parsing the CoffeeScript, making changes to the tree and then generating the CoffeeScript file again, but there's no ready-made solution for this, making it a lot of work unfortunately.

coffeescript itself can take a CoffeeScript-file and turn it in to a syntax tree (I do that in this gist), but it can only turn that tree into JavaScript, not CoffeeScript.

js2coffee can take a tree of JavaScript and turn it into CoffeeScript, but the two trees are not compatible with each other (I can't give js2coffee a tree of CoffeeScript generated from coffeescript and have it print a CoffeeScript file).

A few approaches one could take:

Take the tree generated from coffeescript and

  1. Turn it into a CoffeeScript file directly, or
  2. Change it into a tree that js2coffee can then turn into CoffeeScript

Maybe the CoffeeScript project would be interested in adding a CoffeeScript AST -> CoffeeScript compiler, but I doubt it, so it would have to be a separate project.

I'm not planning on doing anything with this, but I thought I'd write down my findings.

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

No branches or pull requests

2 participants