5 ms·

There are many issues with the status quo of NPM, but I don't see this addressing any of the real issues. Code formatting is not a problem that a package regist

There are many issues with the status quo of NPM, but I don't see this addressing any of the real issues. Code formatting is not a problem that a package registry should address; having a custom editor simply to use a registry is absurd. If those are the problems you wanted to address, you could've just written a plugin for a few common editors. The real issues that a package repository should address are security and verifiability. Is this package trustworthy? Is the latest minor version bump safe to use? What about dependencies deep down the tree? How to automatically detect when a package has been hijacked? How to handle benign package takeovers, e.g. package owner deciding to give ownership to maintainers. Etc etc.

Hamuko 7y ago
How are you even going to force a single way of formatting when JS devs can't even agree on including/excluding semicolons?
- fiddlerwoaroof 7y ago
  Tools like prettier have gone a long way to standardizing formatting in JS.
  - Aeolun 7y ago
    Yeah, it’s just a matter of saying ‘we use prettier’ and that kills all discussion on coding standards.
    - yawaramin 7y ago
      Prettier only enforces formatting standards. Coding standards are a different matter.
      - antigirl 7y ago
        eslint?
  - paulddraper 7y ago
    Agreed. Prettier is de facto standard for new projects. It lets you choose quote character, indentation size, and that basically it.
    - michaelcampbell 7y ago
      Well... https://prettier.io/docs/en/options.html https://prettier.io/docs/en/options.html
      - paulddraper 7y ago
        > --tab-width > --single-quote I mentioned. > --use-tabs Relates to the "indentation width." > --print-width Yes, that's another big user-configurable parameter. > --trailing-comma This exists only for JS version compatibility. > --no-semi > --no-bracket-spacing > --arrow-parens Yeah, those are there too. --- But that's really it for JavaScript formatting options. Like I said, this produces very standardized code in the ecosystem. Compare to clang-format (which suports JavaScript): http://releases.llvm.org/5.0.0/tools/clang/docs/ClangFormatStyleOptions.html http://releases.llvm.org/5.0.0/tools/clang/docs/ClangFormatS...
        onion2k 7y ago
        clang-format is nice but it's closer to eslint than Prettier. It does a lot more than just enforcing what the code looks like.
    - 9935c101ab17a66 7y ago
      As michaelcampbell pointed out, prettier has ~20 pretty robust configuration options, and it's not exactly obscure information. If you're already aware of this, what do you feel is missing?
      - another-dave 7y ago
        I thought GP was saying "that's it" as in, "no more discussions about it" not "that's all it can do".
  - HJain13 7y ago
    I recently had an idea, where a plugin could apply my coding style to code, when I open the code but when I save, it saves it back in coding style for whoever/organisation I'm working for. Didn't find a plugin that already did that, do you guys know of one?
    - 9935c101ab17a66 7y ago
      Yah prettier does this (the tool the person you are replying to mentioned). It's very commonly used in JS dev, alongside things like husky which lets you do things like format code on commit. If you need more info, I can try and point you in the right direction.
      - rgoulter 7y ago
        I've seen Husky+Prettier used to format on the pre-commit hook. Is "format on checkout" common? That'd make 'git diff' quite noisy.
- notatoad 7y ago
  Linters exist. if you want to enforce a formatting standard for your new package registry, why not just reject anything that fails some published eslintrc?
- michaelcampbell 7y ago
  Not the OP, but like any other formatter where choice is involved: You pick one and go with it. See: Black for Python.
norswap 7y ago
What are the issues with NPM? (genuine question) From my (admittedly not super deep) experience with multiple package manager (Maven, Gradle, LuaRocks, Ruby gems, the abominable circus of tools they use the Python environment, ...), I found NPM to be by far the most reliable/easy-to-use tool. That being said, being the best is not necessarily the end goal when the competition is terrible.
- aphextron 7y ago
  Enforcing publishing through source control only is a huge step forward. The current NPM process of allowing anyone with write access to publish a package at will is really insecure. I think that's the most exciting thing I've seen about Pika that NPM lacks.
  - icebraining 7y ago
    Won't this allow anyone with write access to the source code repository to publish a package? Seems just one extra layer of indirection.
    - edoceo 7y ago
      Yes, but now only one place to get rekt - the source which (presumably) has tighter ACL than the package manager? The old way had risk at two steps and now it's reduced 50%
      - icebraining 7y ago
        On the contrary; repositories usually involve many people pushing to them, whereas a package release could be handled by just one person (with maybe one or two for backup). Plus, what about package signing? If the released version comes directly from the repo, does that mean the final package isn't signed by a maintainer?
      - pvorb 7y ago
        Since most source code will be maintained via Git, there's almost no security at all, since you can easily rewrite Git history.
godDLL 7y ago
From the homepage: "every Pika package also is published to NPM" This is not a fix for NPM. This is tooling, convenience.

Hamuko 7y ago

How are you even going to force a single way of formatting when JS devs can't even agree on including/excluding semicolons?

fiddlerwoaroof 7y ago
Tools like prettier have gone a long way to standardizing formatting in JS.
- Aeolun 7y ago
  Yeah, it’s just a matter of saying ‘we use prettier’ and that kills all discussion on coding standards.
  - yawaramin 7y ago
    Prettier only enforces formatting standards. Coding standards are a different matter.
    - antigirl 7y ago
      eslint?
- paulddraper 7y ago
  Agreed. Prettier is de facto standard for new projects. It lets you choose quote character, indentation size, and that basically it.
  - michaelcampbell 7y ago
    Well... https://prettier.io/docs/en/options.html https://prettier.io/docs/en/options.html
    - paulddraper 7y ago
      > --tab-width > --single-quote I mentioned. > --use-tabs Relates to the "indentation width." > --print-width Yes, that's another big user-configurable parameter. > --trailing-comma This exists only for JS version compatibility. > --no-semi > --no-bracket-spacing > --arrow-parens Yeah, those are there too. --- But that's really it for JavaScript formatting options. Like I said, this produces very standardized code in the ecosystem. Compare to clang-format (which suports JavaScript): http://releases.llvm.org/5.0.0/tools/clang/docs/ClangFormatStyleOptions.html http://releases.llvm.org/5.0.0/tools/clang/docs/ClangFormatS...
      - onion2k 7y ago
        clang-format is nice but it's closer to eslint than Prettier. It does a lot more than just enforcing what the code looks like.
  - 9935c101ab17a66 7y ago
    As michaelcampbell pointed out, prettier has ~20 pretty robust configuration options, and it's not exactly obscure information. If you're already aware of this, what do you feel is missing?
    - another-dave 7y ago
      I thought GP was saying "that's it" as in, "no more discussions about it" not "that's all it can do".
- HJain13 7y ago
  I recently had an idea, where a plugin could apply my coding style to code, when I open the code but when I save, it saves it back in coding style for whoever/organisation I'm working for. Didn't find a plugin that already did that, do you guys know of one?
  - 9935c101ab17a66 7y ago
    Yah prettier does this (the tool the person you are replying to mentioned). It's very commonly used in JS dev, alongside things like husky which lets you do things like format code on commit. If you need more info, I can try and point you in the right direction.
    - rgoulter 7y ago
      I've seen Husky+Prettier used to format on the pre-commit hook. Is "format on checkout" common? That'd make 'git diff' quite noisy.
notatoad 7y ago
Linters exist. if you want to enforce a formatting standard for your new package registry, why not just reject anything that fails some published eslintrc?
michaelcampbell 7y ago
Not the OP, but like any other formatter where choice is involved: You pick one and go with it. See: Black for Python.

norswap 7y ago

What are the issues with NPM? (genuine question) From my (admittedly not super deep) experience with multiple package manager (Maven, Gradle, LuaRocks, Ruby gems, the abominable circus of tools they use the Python environment, ...), I found NPM to be by far the most reliable/easy-to-use tool. That being said, being the best is not necessarily the end goal when the competition is terrible.

aphextron 7y ago
Enforcing publishing through source control only is a huge step forward. The current NPM process of allowing anyone with write access to publish a package at will is really insecure. I think that's the most exciting thing I've seen about Pika that NPM lacks.
- icebraining 7y ago
  Won't this allow anyone with write access to the source code repository to publish a package? Seems just one extra layer of indirection.
  - edoceo 7y ago
    Yes, but now only one place to get rekt - the source which (presumably) has tighter ACL than the package manager? The old way had risk at two steps and now it's reduced 50%
    - icebraining 7y ago
      On the contrary; repositories usually involve many people pushing to them, whereas a package release could be handled by just one person (with maybe one or two for backup). Plus, what about package signing? If the released version comes directly from the repo, does that mean the final package isn't signed by a maintainer?
    - pvorb 7y ago
      Since most source code will be maintained via Git, there's almost no security at all, since you can easily rewrite Git history.

godDLL 7y ago

From the homepage: "every Pika package also is published to NPM" This is not a fix for NPM. This is tooling, convenience.