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

Why not use a scoped package for nps? #254

Closed
justin-calleja opened this Issue Feb 21, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@justin-calleja

justin-calleja commented Feb 21, 2017

Hi Kent,

I'm not sure about the history of the nps project, but reading this made me wonder why you guys didn't just use a scoped package to solve this issue.

I'm second guessing my decision to scope my npm packages… pretty much all packages I use are not scoped. Brought this up here too: http://stackoverflow.com/questions/42377534/is-the-lack-of-scoped-npm-packages-due-to-recency-of-this-feature

What's your stand on npm scoped packages? When publishing your modules, do you intentionally avoid scoping them?

Thanks!

@kentcdodds

This comment has been minimized.

Owner

kentcdodds commented Feb 21, 2017

Hi @justin-calleja,
This is a great question. I answered it on my podcast here. To sum up:

  • Scoped packages allow you to name your packages whatever you like and when people install them, they install them with npm install @<yourusername>/<yourpackagename> (for example npm install @kadira/storybook)
  • They can make it difficult to remember the name when people install them (people have to look it up every time)
  • They can make it difficult/awkward to transfer ownership of the project
  • They're great for groups of projects
  • They're great for throw away projects.

Thanks!

@kentcdodds kentcdodds closed this Feb 21, 2017

@justin-calleja

This comment has been minimized.

justin-calleja commented Feb 21, 2017

Thanks @kentcdodds 😄

Personally, I think this is the best reason against scoped pkgs (in certain cases): "They can make it difficult/awkward to transfer ownership of the project"

Re difficult to remember:

  • if you use a pkg often enough, you'll remember it
  • if you use a pkg often enough, you probably already have a project you can just copy / paste the dependency name from
  • I'm sure there are plenty of ways to automate / ease this. A package like @kadira/storybook can be included in a "default way of setting up a React project" a la yeoman generator or something. I've only had a quick look at: https://github.com/tinytacoteam/zazu - but it or something like it (a launcher) can be used to quickly search npm regardless of where you're at (browser, terminal, editor etc...).

Re the transfer of ownership of the project. Ye, I'll have to admit that bugs me too. My current mindset is that if it's a "micro" package, something that does only one thing (and that one thing is pretty small) - then I'm quite comfortable scoping it. It's unlikely to need too much maintaining after writing. Also, anyone can easily fork the project and publish under their username. The point of the pkg is to not have to repeat code if it's already written.

If the pkg isn't just a function or two, I think I'll stick with unscoped 😄

Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment