Make sure a custom blueprint will be used if it's not the default blueprint

[gitstevenpham]

Bug

I wanted to update the state of my project with changes to a blueprint from an Ember addon package that is not the default:

{
  "schemaVersion": "1.0.0",
  "packages": [
    {
      "name": "ember-cli",
      "version": "3.23.0",
      "blueprints": [
        {
          "name": "addon",
          "outputRepo": "https://github.com/ember-cli/ember-addon-output",
          "codemodsSource": "ember-addon-codemods-manifest@1",
          "isBaseBlueprint": true,
          "options": [
            "--welcome",
            "--yarn"
          ]
        }
      ]
    },
    {
      "name": "@stpham/generic-addon",
      "version": "0.0.2",
      "blueprints": [
        {
          "name": "@stpham/bootstrapping-project"
        }
      ]
    }
  ]
}

When I run ember-cli-update and choose @stpham/bootstrapping-project, the @stpham/generic-addon version is bumped but the actual blueprint changes aren't there. i.e. file additions.

Root Cause

It seems like the code assumes the default blueprint would be the only blueprint that would be used

async function emberInstallAddon({
  cwd,
  addonNameOverride,
  packageName,
  version,
  blueprintPath,
  stdin
}) {
  let addon;

  if (addonNameOverride) {
    addon = addonNameOverride;
    if (version && !blueprintPath) {
      addon += `@${version}`;
    }
  }

  if (!addon) {
    addon = blueprintPath;
  }

  if (!addon) {
    addon = `${packageName}@${version}`;
  }

  let install = ember(['i', addon], { cwd, stdin });

  let generate;

  if (!blueprintPath) {
    generate = install;
  } else {
    let emberCliVersion = await getEmberCliVersion({ cwd });

    let isBuggyEmberCliVersion = semver.satisfies(emberCliVersion, buggyEmberCliRange);

    if (!isBuggyEmberCliVersion) {
      generate = install;
    } else {
      await install;

      generate = ember(['g', packageName], { cwd, stdin });
    }
  }

  return {
    ps: generate
  };
}

The generate = ember(['g', packageName], { cwd, stdin }); line will only be hit if the ember-cli version is deemed to be a buggy one else it only uses ember install <package>.

Changes

End User Experience

After these changes are pushed, the end-user will be required to provide a blueprint name with the install command if they want to use another blueprint that doesn't match the addon name. ember-cli-update install <package_name> will assume there exists a blueprint with the same name as <package_name>. ember-cli-update install <package_name> -b <some_other_blueprint> to install package and ember g <some_other_blueprint>.

We should release version 1.0.0 to indicate the above requirement exists for custom blueprints. Judging that this problem has existed for a while, I don't think many folks use ember-cli-update for custom blueprints

Code Changes

I opted to move away from using ember install <package_name> to install packages since it will automatically try to generate the default blueprint. Since there will always be a blueprint name in the ember-cli-update.json tied to a package (I assume), I figured the code can be more explicit in what it is doing. I refactored and renamed ember-install-addon.js to install-and-generate-blueprint.js and made it always install a package and generate the specified blueprint.

[rwjblue]

@spham92 - Looks like we have a conflict over in:

src/get-start-and-end-commands.js

[rwjblue]

FWIW, the last failing job is due to the issue I created #1085 to track (fork PRs can never pass CI at the moment).

[gitstevenpham]

@kellyselden can you take a look at the PR when you get a chance?

[gitstevenpham]

ping @kellyselden

[gitstevenpham]

ping @kellyselden

[kellyselden]

I don't see this logic block in the new version. Is that going to be a problem?

[gitstevenpham]

Let me know if I missed a use case.

I moved the responsibility of choosing which blueprint to use up to the parent function that calls installAndGenerateBlueprint.

install command will default to the addon name if a blueprint param is not passed by the user.

line 45-53 of src/install.js

  let { ps } = await installAndGenerateBlueprint({
    cwd,
    addonNameOverride: addon,
    packageName,
    blueprintPath: path
    blueprintName: _blueprintName || addon,
    blueprintPath: path,
    packageManager: isYarnProject ? 'yarn' : 'npm'
  });

installAddonBlueprint also will pass a blueprintName param

line 275-284 of src/get-start-and-end-command.js

let { ps } = await installAndGenerateBlueprint({
    cwd: projectRoot,
    packageName: blueprint.packageName,
    version: blueprint.version,
    blueprintPath: blueprint.path,
    stdin: 'pipe'
    blueprintName: blueprint.name,
    blueprintOptions: blueprint.options || [],
    stdin: 'pipe',
    packageManager
  });

[kellyselden]

if you don't mind double checking all of these that can be removed now that the test isn't stubbing anymore.

[gitstevenpham]

We still need these for the actual unit test of this module

[kellyselden]

Looking good. I have a few more suggestions. I checked out the code and stepped through the tests, so I have a better understanding of the functionality now :)

[gitstevenpham]

@kellyselden current state of code addresses the PR comments

[kellyselden]

After the initial install, will someone be able to update this blueprint?

[kellyselden]

or is it correct that after the initial resolution of the blueprint name from install, we no longer have to worry about it being a name mismatch (and we never have to look it up again)?

[gitstevenpham]

The latter is correct. Once the blueprint name is set in ember-cli-update.json it will be the one generated when user wants to update the package version the blueprint belongs to.

[gitstevenpham]

Friendly reminder @kellyselden

[kellyselden]

nitpick but this test should be moved to a new file test/integration/get-default-blueprint-name-override-test.js

[kellyselden]

as well as the above one which is testing the disk blueprints

[gitstevenpham]

done!