ember-cli / blprnt Goto Github PK

currently supports:

• by arguments[0] + lookup paths { paths: [ .. ] }

should also support:

• absolute path.isAbsolute(arguments[0])
• support relative /^\.\//.test(arguments[0]))

• clean-remove
• insert-into-file
• markdown-color
• open-editor
• print-command
• printable-properties
• process-template
• walk-up-path
• blueprint
  • shake out unit tests
  • improve unit coverage
• edit-file-diff ( needs tests )
  • implement tests
• improve unit file-info test coverage
  • .checkForConflict
  • .confirmOverwriteTask

• how to use it
• more detailed usage (or defer to API docs)
• features

• file-edits writeFile before final blueprint commit
  • https://github.com/ember-cli/blprnt/blob/master/lib/edit-file-diff.js#L56-L58

By fixing ^ both should once again work.

This is being extracted from an existing code-base. For good reasons:

• improve quality
• improve iteration velocity
• make accessible to other efforts (i atleast have needed this in the past elsewhere)
• it as originally intended as such

Although the License remains the same, but the git commit history is a tad tricky to restore. So at a very least, we can give a shoutout to those contributors in the readme or in a separate contributors.md file.

ember-cli/ember-cli#6768

Some blueprints may require asynchronous logic to be performed for some hooks that are currently run synchronously. This was currently worked around by the following PR: ember-cli/ember-cli#3199 by passing in the resolved locals, to then mutate as necessary. To avoid this, we could make the locals and fileMapTokens hooks promise aware.

We should also investigate any other hooks that may benefit from allowing asynchronous operations.

Hi, considering this gist and its changes: https://gist.github.com/jgwhite/1e7871f886a9836c33d3/revisions

There is a need to "extend" blueprints in order to be able to easily change or extend the templates that the blueprints are using while not changing any installation logic (i.e. needed packages and the like). The current approach is to use `this.lookupBlueprint('name') and then call the appropriate method on it, like

afterInstall: function() {
    return this.lookupBlueprint('name').afterInstall();
}

This currently can lead to errors if the parent blueprint invokes tasks like npm install because the context isn't correct. What would be nice is something like an origin method that does the exact same thing while taking care of the environment stuff.

someHook: function(options) {
    return this.origin();
}

Simliar to this.super in ember.js it should take care of the arguments by itself. The method should still take arguments in order to be able to change them. I avoided the name super because its not actually the same concept as to call a "super" method.

If the need for calling different hooks from the origin there could be something like originInvoke()

someHook: function(options) {
    return this.originInvoke("otherhook");
    return this.invokeOnOirigin("otherhook");
    return this.invokeOrigins("otherhook");
    return this.callOrigins("otherhook");
}

• https://github.com/ember-cli/blueprint/blob/master/lib/blueprint.js#L660

• https://github.com/ember-cli/blueprint/blob/master/lib/blueprint.js#L783-L802

• provide boundary for abstract tasks taskFor('npm-install)maybe rename tonode_module:install` and external consumer can provide the functionality

  • load tasks via what the consumer provides: https://github.com/ember-cli/blueprint/blob/master/lib/blueprint.js#L1107

• provide standalone UI abstraction that can be provided, otherwise have ember-cli provide that UI.

• load blueprints based on provided lookup strategy:

  • https://github.com/ember-cli/blueprint/blob/master/lib/blueprint.js#L1244
  • https://github.com/ember-cli/blueprint/blob/master/lib/blueprint.js#L1271
  • https://github.com/ember-cli/blueprint/blob/master/lib/blueprint.js#L1298

• https://github.com/ember-cli/blueprint/blob/master/lib/blueprint.js#L1479-L1480

• in-report addon stuff: https://github.com/ember-cli/blueprint/blob/master/lib/blueprint.js#L435

• references to pod

• references to ember-cli

  • https://github.com/ember-cli/blueprint/blob/1ee765ee6adb9df8bd627f50e53c52c2ba082498/lib/blueprint.js#L27

As mentioned in ember-cli/ember-cli#3664, a blueprint should take into account an existing .editorconfig file while generating a file.
We could likely achieve this by running the output through a babel-codemod plugin.