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

ember new #66

Closed
stefanpenner opened this issue Mar 14, 2014 · 11 comments
Closed

ember new #66

stefanpenner opened this issue Mar 14, 2014 · 11 comments

Comments

@stefanpenner
Copy link
Contributor

by popular request

essentially mkdir project-name && cd project-name && ember init

@knownasilya
Copy link
Contributor

With all init options available?

ember new folderName [app-name] [--skip-npm-install]

Where app-name defaults to folder name, but Pascal Cased? Should --dry-run be included, doesn't seem to make sense in this context.

@stefanpenner
Copy link
Contributor Author

ya, no dry-run

app-name dasherized as well I think

@knownasilya
Copy link
Contributor

So something like: ember new folderName [--app-name] [--skip-npm-install]

@stefanpenner
Copy link
Contributor Author

just ember new <app-name> i think the folder name being different then the app is so uncommon, people can just rename after.

@knownasilya
Copy link
Contributor

I disagree, and if that was my only option, I'd do ember new App every time, and then rename the folder:

ember new App
mv App/ my-blog/

So now virtually the shortcut of the new command has become a 'longcut' 😉

@stefanpenner
Copy link
Contributor Author

@knownasilya although that may be your path, I do not feel that is the common scenario.

I am quite nervous adding many flags and options to handle every possible permutation.

@marcioj
Copy link
Contributor

marcioj commented Mar 17, 2014

@stefanpenner I guess we can close that issue

@Blackshawk
Copy link
Contributor

@stefanpenner Auto-dasherizing the folder name does seem a bit odd. I ran bin/ember new TestApp today in my projects folder (which has ~ 200 folders in it). It took me a minute to realize what had happened and that the created directory was test-app.

I think dasherizing the app name in package.json, app.js, for module prefixes, etc. is great. But the root directory? My 2¢ is that it will confuse more than it helps.

@stefanpenner
Copy link
Contributor Author

@Blackshawk ya, I agree. Will accept PR + test :)

@Blackshawk
Copy link
Contributor

@stefanpenner Will oblige when I get back home. Its late. :) Good talk today, btw.

@MajorBreakfast
Copy link
Contributor

I for one am not opposed to not dasherizing the folder name. Only the package name is a must. But I think you agree with me on that. Let's see what the others think.

Blackshawk added a commit to Blackshawk/ember-cli that referenced this issue Mar 27, 2014
* Behavior change
* Adds acceptance test to cover new behavior

Currently, running ```ember new FooApp``` will generate a folder called ```foo-app```. As discussed this is a potential source of confusion for users, who will expect a directory called ```FooApp``` to be created.

This commit changes the behavior so that the created directory is called ```FooApp```. However, it maintains the lowercase, dasherized name in the generated package.json file.
stefanpenner added a commit that referenced this issue Mar 27, 2014
Issue #66 - Create directory as specified by user input
homu added a commit that referenced this issue Jan 9, 2017
Update execa to the latest version 🚀

## Version **0.6.0** of [execa](https://github.com/sindresorhus/execa) just got published.

<table>
  <tr>
    <th align=left>
      Dependency
    </td>
    <td>
      execa
    </td>
  </tr>
  <tr>
    <th align=left>
      Current Version
    </td>
    <td>
      0.5.1
    </td>
  </tr>
  <tr>
    <th align=left>
      Type
    </td>
    <td>
      dependency
    </td>
  </tr>
</table>

The version **0.6.0** is **not covered** by your **current version range**.

Without accepting this pull request your project will work just like it did before. There might be a bunch of new features, fixes and perf improvements that the maintainers worked on for you though.

I recommend you look into these changes and try to get onto the latest version of execa.
Given that you have a decent test suite, a passing build is a strong indicator that you can take advantage of these changes by merging the proposed change into your project. Otherwise this branch is a great starting point for you to work on the update.

---

<details>
<summary>Commits</summary>
<p>The new version differs by 3 commits .</p>
<ul>
<li><a href="https://urls.greenkeeper.io/sindresorhus/execa/commit/af6667af5efcfc1470606ce5eb433017c3b3ae0a"><code>af6667a</code></a> <code>0.6.0</code></li>
<li><a href="https://urls.greenkeeper.io/sindresorhus/execa/commit/c8c9c7be52e7292d782f25e979f21c0d5aae57f6"><code>c8c9c7b</code></a> <code>Throw error in sync method - fixes #66 (#67)</code></li>
<li><a href="https://urls.greenkeeper.io/sindresorhus/execa/commit/1a41fac8600a165ba1b6a738e112f51a25370df2"><code>1a41fac</code></a> <code>Bump dependencies</code></li>
</ul>
<p>See the <a href="https://urls.greenkeeper.io/sindresorhus/execa/compare/e5598cf42a5433ff1f7954f9cd31a57b429d4875...af6667af5efcfc1470606ce5eb433017c3b3ae0a">full diff</a>.</p>
</details>

<details>
<summary>Not sure how things should work exactly?</summary>

There is a collection of [frequently asked questions](https://greenkeeper.io/faq.html) and of course you may always [ask my humans](https://github.com/greenkeeperio/greenkeeper/issues/new).
</details>

---

Your [Greenkeeper](https://greenkeeper.io) Bot 🌴
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants