Blueprints Update #477
Blueprints Update #477
Conversation
|
Looks like you need the canonical link in the description - https://github.com/emberjs/rfcs/blob/464855635effeda3ea183d9438bbc8e86d99b4b0/text/0477-blueprints-update.md |
|
@meirish Can you try again? I updated the link. |
kellyselden
force-pushed
the
blueprints-update
branch
from
06ff613 to
29e60fe
Compare
|
Awesome! I think this would be fantastic. Personally, I am perpetually confused by the various state files in Ember projects... add to that our own build and CI tools, the top level of a project directory quickly becomes intimidating for new users. I would love to see this go in an existing file or even package.json to avoid Yet Another File. It would also be super important for the file to state if it can be changed by end users or not and what effect it would have, so JSON format (sans comments) would be less than ideal, IMO. |
|
@mehulkar I've found via further testing that mixing a file that is tracked by the default ember-cli blueprint (.ember-cli, package.json) and modified by ember-cli-update (to update the blueprint metadata), it gets cumbersome. Both processes try to edit the same file. So in theory, ember-cli could alter the .ember-cli file in a way that conflicts with what you have in yours. This would give you a git conflict, then the updater can't read it anymore because it is in a state of invalid JS. I think this further supports a separate file. |
|
That makes sense |
|
Added sections about complete vs partial blueprints, saving options, and supporting custom blueprint codemods. |
text/0477-blueprints-update.md
Outdated
| } | ||
| ``` | ||
|
|
||
| I vote “ember-cli-update.json”. Since the code will be modified by the updater, it’s easier to reformat JSON. “.ember-cli” I think supports JS, so it would be hard to modify. “package.json” seems like an abuse to put more metadata in there. |
There was a problem hiding this comment.
Agreed, lets drop the other examples and focus specifically on the stand alone ember-cli-update.json.
text/0477-blueprints-update.md
Outdated
| Blueprints could be responsible for injecting the state into projects | ||
|
|
||
| ```js | ||
| // my-custom-blueprint/blueprints/my-custom-blueprint/files/.ember-cli |
There was a problem hiding this comment.
Let's consolidate all examples in this RFC on the ember-cli-update.json format. I find it pretty confusing to jump amongst 2 or 3 different formats while reviewing.
text/0477-blueprints-update.md
Outdated
|
|
||
| **Complete vs partial** | ||
|
|
||
| We need a way to denote a project replacement blueprint and a supplemental blueprint. A project replacement removes any sort of default ember-cli blueprint tracking, even if it still looks like a normal Ember project (has ember-cli, ember-addon, etc.). A supplemental blueprint is one that piggy-backs on a complete blueprint and makes certain tweaks to files. Think of ember-cli-mirage's extra project configs, or your company's custom settings on top of a normal Ember app. |
There was a problem hiding this comment.
Why do we need to know the difference between complete and partial? I think you are basically saying that we need to know the difference between the original project blueprint (aka the "root" blueprint) and the others so that we know how to build up the comparison diff, is that right?
There was a problem hiding this comment.
At the time of writing this, I thought I would need to know the difference between the two to do the correct thing, but after implementing most the functionality, I don't think that's true anymore.
|
A few things here:
|
|
RE: format for the blueprints array within Here is what I was thinking (based on reading through this RFC, and looking at some of what was implemented already): interface BlueprintConfig {
/**
Is this the initial project blueprint (e.g. `ember new` or `ember addon`)?
*/
isRoot: boolean;
/**
The name of the blueprint to be ran.
*/
name: string;
/**
The package the blueprint comes from.
*/
package: string;
/**
The version of the package above to use.
*/
version: string;
/**
The path the blueprint is ran from.
*/
rootPath: string;
/**
The blueprint command line options.
*/
options?: {
/**
The positional arguments to pass to the blueprint.
*/
positional?: string[];
/**
The named arguments to pass into the blueprint.
*/
named?: {
[key: string]: string;
};
}
} |
Good idea. Is there precedence for how a third party could use the same logic to detect this? Filed ember-cli/ember-cli-update#675 and ember-cli/ember-cli-update#680.
Great idea. Filed ember-cli/ember-cli-update#676. As far as the blueprint schema:
|
Ya, agree. Though I think we could solve it by offering a way to run a single blueprint at a time. The default would be the thing we’ve been talking about (run them all in sequence, then diff, then apply), but we would also be able to have a command to run just one. |
woah good to know! |
|
What I want is for It would then be up to addons to use that in a standard I like that this RFC introduces a place in a project under version control for tracking just this! What I dislike about this RFC is it seems to get us further away from the broader community's tooling expectations. I shouldn't need to know that for project-x I need to install a new dependency with |
|
I'm struggling to figure out how best to store the options. The goal is to both regenerate CLI commands and match codemod requirements. For example, you want to be able to generate but you also want to be able to target a codemod with requirements like {
"versions": {
"ember-cli": "2.16.0-beta.1"
},
"projectOptions": ["app", "addon", "welcome"],
"nodeVersion": "4.0.0",
"commands": ["ember-modules-codemod"]
}The codemod schema is going to need some work, but the idea is you want to gate the codemod on the presence of options. If we store CLI arguments verbatim {
"name": "ember-cli",
"version": "3.2.0-beta.1",
"options": {
"positional": [
"--no-welcome"
]
}
}we are not going to match any codemod requirements that don't know about the We could either mirror ember-cli's argument parsing, which is going to be brittle, or nudge people somehow to store normalised options in the config so that codemods can match them. |
|
I'm starting to flesh out more ideas here https://github.com/ember-cli/ember-cli-update/wiki/Config-Schema |
|
I added the latest config schema that I've been iterating on here. I think this RFC is now ready to progress. I implemented all the features behind opt-in commands, and I've extensively tested them in the real world. The config schema now feels solid with room to grow. |
|
@kellyselden - Awesome! Would you mind opening an issue to track feedback (and include instructions on how to leverage the new commands and whatnot)? I'd love to kick the tires 😸 |
|
@rwjblue Here you go ember-cli/ember-cli-update#812. |
|
@rwjblue you mentioned storing the config in |
|
Yes, the top level |
|
Now that Octane is out and the Holidays are over, I'd love to make progress on this. Anything remaining to be addressed? This is already extremely useful in my various projects: // existing ecosystem support (default addon blueprints) // partial ember blueprints // tracking custom blueprints (libkit) // used as node templates (non-ember) |
|
just saw a demo of this. I'm a fan 👍 |
|
@NullVoxPopuli Can you please share the demo link here |
|
I cannot -- it was an internal / work demo (to/for CrowdStrike) |
|
I think it's about time I put this into FCP. I'll ask someone to merge it in a week, or else just close it. |
|
Sorry @kellyselden, I forgot to add the label when you pinged. FYI - We are moving this into final comment period, and barring new issues being discovered will merge it in about a weeks time. |
|
@rwjblue Do you mind merging this? |
|
The feature was released, so can someone please merge or close this. |
|
Whoops! Merging it :) |
|
As always, thanks to everyone that gave us their input to improve the proposal! |
Enables apps and addons to update ember-cli without impacting future `ember-cli-update` runs. Without this `ember-cli-update` will use the current version of `ember-cli` in the `package.json` to determine which version to attempt to update _from_. Unfortunately, this means that if you were to update your `ember-cli` version without _also_ running the full blueprint update, you would have a much harder time of updating your general project structure in the future. Support for this format and process was nailed down and merged in [emberjs/rfcs#477](https://github.com/emberjs/rfcs/blob/master/text/0477-blueprints-update.md).
Rendered