5 ms·

No alert box ever will save you from doing the biggest mistakes, most people don’t read them.

by vvoyer 8y ago

ivan_gammel 8y ago
Just compare this to publication to Maven Central - you’ll never publish there by accident exactly because there are significant barriers. Public NPM repo should not be that easily accessible for upload.
- kbenson 8y ago
  At some points in a language and its package management system's lifetime, reducing barriers to publishing are one of the best things that can be done to increase packages and fill out the ecosystem, and drive utility and adoption. Later, once you have most needs filled by packages, and a good number of enterprise users, more control is beneficial. Companies appreciate it, and single users are willing to jump through an extra hoop or two much of the time because the rest of the ecosystem is so useful that it's not worth switching languages. I think it's unlikely that a system will move from one style to another without an event causing them to reevaluate their prior choices. More likely, multiple events. This has already happened with NPM for other choices they made in the past, such as letting package namespaces be claimed by new people after someone gives it up, and whether releases are immutable, IIRC.
  - ljm 8y ago
    This is going to be cynical, but as far as I understand it people are looking for usability through vanity. Why not install `com.facebook.react’? Reverse domain notation is remarkably elegant given our internet. You are not typing ‘npm i com.facebook.react’ so often that it’s a pain. You probably use ‘create-react-app’ which is even worse. Instead, every language creates a new cash grab for common names. And made it worse. New namespaces, new squatting. I can publish ‘react-racket’ and do whatever I want behind the scenes with it. Case in point: do you add coffeescript or coffee-script. Why optimise for keystrokes in your term instead of stability for your client? Jesus fuck.
    - kall 8y ago
      There's a little bit of movement happening in that direction in the npm world with scoped packages. E.g. babel moving all official packages to @babel. Storybook does it too. Doesn't even have to be much of a branding loss. FB could publish @react/react, @react/native, @react/eslint-config, @react/create-app, @react/prop-types, @react/dom... Most of the typing is happening in require/import not npm install, so there's some argument for not going the full java route.
    - gowld 8y ago
      The JavaScript community is moving into the Enterprise and is discovering Java's good ideas from 1995
      - bigiain 8y ago
        Excellent. A whole quarter of a century, or perhaps half of the entire software industries lifetime, of exciting known security errors to look forward to! BRB, off to hide all my bitcoin under my mattress...
    - jeswin 8y ago
      > Why not install `com.facebook.react’? That would be a bad idea, and it's not just brevity. - If com.facebook.hr has previously been published, would it mean that facebook can never have a division named HR? - Once a company goes belly up, the domain often ends up with squatters/spammers. Domains with published packages will sell for a lot more in the underground market - for pure exploitation of rights to publish a newer version. - In the absence of validation, nothing stops anyone from publishing com.google.exploitlib. And domain validation is friction. - Most publishers on npm may not have a domain. And finally like someone mentioned below, npm already supports scoped packages. https://docs.npmjs.com/about-scopes https://docs.npmjs.com/about-scopes
      - oblio 8y ago
        Regarding your concerns, some friction is necessary. Without friction I can skate, but I can't drive.
  - lugg 8y ago
    Please don't think this way. This is such a solvable problem. Doesn't package.json have an is private repo flag? Why not just respect that? Why does everyone everyone in this thread think a pop up is the solution? Pop ups are a code smell. They mean your application does not correctly match user intent with the action so badly you had to specifically get your user to tell you what they meant to do. Did you mean to do that? Always, yes. Otherwise, undo. The only place did you mean makes sense is in Google search results. Why is public and private publish anywhere near each other? Why are they even on the same page? Stop drawing boundaries around nouns.
    - kall 8y ago
      npm publish already prevents you from publishing a package that has the private flag. They must not have had it set.
    - alexanderdmitri 8y ago
      I disagree, there have been times a well-placed popup stopped me from accidentally doing something really stupid, other times there wasn't a popup and I ended up doing something stupid. It doesn't necessarily have to be a pop up popup per say, but extra validation around dangerous actions is user friendly. And of course there can always be an override for the extra validation in case it potentially screws up some people's workflows, but I'd make a user explicitly set the override, like the 'NoHostAuthenticationForLocalhost' option in ssh for example.
      - gowld 8y ago
        Popups only work if they Confirm button is not a button, but "enter this text exactly: I really want to publish this package to the whole wide world" and block copy-paste. If the user hacks around that, it's their own fault.
      - lugg 8y ago
        If a pop up is required to prevent you doing something stupid the UX has already failed. I don't think a popup solving a problem means it is solving the right problem in the right way.
deleted 8y ago
[deleted]

No alert box ever will save you from doing the biggest mistakes, most people don’t read them.

by vvoyer 8y ago

No alert box ever will save you from doing the biggest mistakes, most people don’t read them.

Just compare this to publication to Maven Central - you’ll never publish there by accident exactly because there are significant barriers. Public NPM repo should not be that easily accessible for upload.

kbenson 8y ago
At some points in a language and its package management system's lifetime, reducing barriers to publishing are one of the best things that can be done to increase packages and fill out the ecosystem, and drive utility and adoption. Later, once you have most needs filled by packages, and a good number of enterprise users, more control is beneficial. Companies appreciate it, and single users are willing to jump through an extra hoop or two much of the time because the rest of the ecosystem is so useful that it's not worth switching languages. I think it's unlikely that a system will move from one style to another without an event causing them to reevaluate their prior choices. More likely, multiple events. This has already happened with NPM for other choices they made in the past, such as letting package namespaces be claimed by new people after someone gives it up, and whether releases are immutable, IIRC.
- ljm 8y ago
  This is going to be cynical, but as far as I understand it people are looking for usability through vanity. Why not install `com.facebook.react’? Reverse domain notation is remarkably elegant given our internet. You are not typing ‘npm i com.facebook.react’ so often that it’s a pain. You probably use ‘create-react-app’ which is even worse. Instead, every language creates a new cash grab for common names. And made it worse. New namespaces, new squatting. I can publish ‘react-racket’ and do whatever I want behind the scenes with it. Case in point: do you add coffeescript or coffee-script. Why optimise for keystrokes in your term instead of stability for your client? Jesus fuck.
  - kall 8y ago
    There's a little bit of movement happening in that direction in the npm world with scoped packages. E.g. babel moving all official packages to @babel. Storybook does it too. Doesn't even have to be much of a branding loss. FB could publish @react/react, @react/native, @react/eslint-config, @react/create-app, @react/prop-types, @react/dom... Most of the typing is happening in require/import not npm install, so there's some argument for not going the full java route.
  - gowld 8y ago
    The JavaScript community is moving into the Enterprise and is discovering Java's good ideas from 1995
    - bigiain 8y ago
      Excellent. A whole quarter of a century, or perhaps half of the entire software industries lifetime, of exciting known security errors to look forward to! BRB, off to hide all my bitcoin under my mattress...
  - jeswin 8y ago
    > Why not install `com.facebook.react’? That would be a bad idea, and it's not just brevity. - If com.facebook.hr has previously been published, would it mean that facebook can never have a division named HR? - Once a company goes belly up, the domain often ends up with squatters/spammers. Domains with published packages will sell for a lot more in the underground market - for pure exploitation of rights to publish a newer version. - In the absence of validation, nothing stops anyone from publishing com.google.exploitlib. And domain validation is friction. - Most publishers on npm may not have a domain. And finally like someone mentioned below, npm already supports scoped packages. https://docs.npmjs.com/about-scopes https://docs.npmjs.com/about-scopes
    - oblio 8y ago
      Regarding your concerns, some friction is necessary. Without friction I can skate, but I can't drive.
- lugg 8y ago
  Please don't think this way. This is such a solvable problem. Doesn't package.json have an is private repo flag? Why not just respect that? Why does everyone everyone in this thread think a pop up is the solution? Pop ups are a code smell. They mean your application does not correctly match user intent with the action so badly you had to specifically get your user to tell you what they meant to do. Did you mean to do that? Always, yes. Otherwise, undo. The only place did you mean makes sense is in Google search results. Why is public and private publish anywhere near each other? Why are they even on the same page? Stop drawing boundaries around nouns.
  - kall 8y ago
    npm publish already prevents you from publishing a package that has the private flag. They must not have had it set.
  - alexanderdmitri 8y ago
    I disagree, there have been times a well-placed popup stopped me from accidentally doing something really stupid, other times there wasn't a popup and I ended up doing something stupid. It doesn't necessarily have to be a pop up popup per say, but extra validation around dangerous actions is user friendly. And of course there can always be an override for the extra validation in case it potentially screws up some people's workflows, but I'd make a user explicitly set the override, like the 'NoHostAuthenticationForLocalhost' option in ssh for example.
    - gowld 8y ago
      Popups only work if they Confirm button is not a button, but "enter this text exactly: I really want to publish this package to the whole wide world" and block copy-paste. If the user hacks around that, it's their own fault.
    - lugg 8y ago
      If a pop up is required to prevent you doing something stupid the UX has already failed. I don't think a popup solving a problem means it is solving the right problem in the right way.

deleted 8y ago

[deleted]