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

Add support for scoped package (Fix #272) #275

Merged
merged 15 commits into from
Mar 27, 2018
Merged

Add support for scoped package (Fix #272) #275

merged 15 commits into from
Mar 27, 2018

Conversation

Myhlamaeus
Copy link
Contributor

Fixes #272
Expands upon #273

I’ve needed this feature quite badly, and have thus made the remaining changes myself.

  • Add tests for repository names with scopes
  • Add tests for invalid repository names
  • Composing with this generator should work again
  • Disambiguate repository name from package name
  • Fix README.md-URLs for scoped packages

SBoudrias and others added 5 commits December 26, 2017 12:50
* change option name from `github-account` to `githubAccount` in
git/index.js (githubAccount is used everywhere else, and the result is
the same)
* change option description in readme/index.js to match the description
in app/index.js
Add the option `repositoryName`, being the ‘Name of the GitHub
repository’.
@Myhlamaeus Myhlamaeus changed the title Fix/scoped package support Add supports for scoped package (Fix #272) Dec 28, 2017
@Myhlamaeus Myhlamaeus changed the title Add supports for scoped package (Fix #272) Add support for scoped package (Fix #272) Dec 28, 2017
@Myhlamaeus
Copy link
Contributor Author

I have opened a related PR SBoudrias/inquirer-npm-name#12 to move the validation of the package name to where it belongs.

@hemanth
Copy link
Member

hemanth commented Dec 29, 2017

LGTM

@hemanth hemanth requested a review from SBoudrias January 3, 2018 03:59
@SBoudrias SBoudrias changed the base branch from fix/scoped-package-support to master January 5, 2018 20:42
repository =
this.options.githubAccount +
'/' +
(this.options.repositoryName || this.options.name);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any case where repositoryName would be null and name have a value? I'd prefer we keep a single option here and let the parent generator pass the proper value.

Copy link
Contributor Author

@Myhlamaeus Myhlamaeus Jan 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They could be falsy both if some other (non-node) generator would compose with this one or if the user would use it directly through yo node:git.

I’ve just tested this—both githubAccount and repositoryName are marked as required, yet there is no error when omitting them.

I agree with removing this fallback, as this is currently the only position at which name is used, and passing an option as a fallback for the case in which another option is not passed seems absurd.

There are, as I see it, three ways to deal with the possibility of having undefined/undefined as the repository:

  • Run only git init --quiet when some options are missing
  • Just ignore it
  • Prompt for the missing values (which would only work when composing with this generator before prompting)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’ve implemented the first of the three options for now.

this.props.repositoryName = this.props.name;

if (this.props.repositoryName.startsWith('@')) {
this.props.repositoryName = this.props.repositoryName
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think here we could also infer the default githubAccount value from the npm scope. (maybe set it as the default of the githubAccount prompt)

If a scoped name is supplied, use the scope part (after the `@` and
before the first `/`) as default value for `githubUser`, even ignoring
the `authorEmail` which is otherwise used to find the default value.
Only write `repository` to the package file if both `githubAccount`
and `repositoryName` are passed to the `git`-generator. Re-read the
package before adding the `origin`-remote to repository in case some
other generator has modified it.
@@ -103,25 +125,38 @@ module.exports = class extends Generator {
}
}

_initModuleName() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's find a better place for this logic. I don't think the side-effets it has because it's making it hard to know exactly when these values end up being created. In the future, I fear this will be hard to debug.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed the side effects from the method and moved them to _askForModuleName, wherein this.props.name was already being set. _askForModuleName only has side effects, so this should be fine; otherwise, I’d suggest moving the setting of the props out of the _ask*-methods and into the prompting-method.

@@ -46,17 +46,21 @@ module.exports = class extends Generator {
);
}

writing() {
_readPkg() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to change this?

If we need to call if before each method, then let's change this to be a local variable rather than a function causing a side-effect on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed the side effects and turned it into a local constant.

Have `_getModuleNameParts` return an object with the parts of the module
name instead of directly writing it to `props`.
Copy link
Member

@mischah mischah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks so much for this PR ❤️

And Sorry, to kept you hanging in here so long.

@mischah mischah merged commit 129c233 into yeoman:master Mar 27, 2018
@mischah
Copy link
Member

mischah commented Mar 27, 2018

Relased with v2.4.0 🎉

@rodoabad
Copy link

@mischah so for scope packages, it's @scope/foo-generator?

@wrumsby
Copy link

wrumsby commented Feb 27, 2020

@rodoabad if your package name is @scope/generator-foo then you should be able to install it with yo @scope/foo.

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

Successfully merging this pull request may close these issues.

Allow using scoped package names
6 participants