Pika – A JavaScript package registry for the modern web(pika.dev)
pika.dev
Pika – A JavaScript package registry for the modern web
https://www.pika.dev/registry
105 comments
From the homepage: "every Pika package also is published to NPM"
This is not a fix for NPM. This is tooling, convenience.
This is not a fix for NPM. This is tooling, convenience.
How are you even going to force a single way of formatting when JS devs can't even agree on including/excluding semicolons?
Tools like prettier have gone a long way to standardizing formatting in JS.
Agreed. Prettier is de facto standard for new projects.
It lets you choose quote character, indentation size, and that basically it.
It lets you choose quote character, indentation size, and that basically it.
> --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/ClangFormatS...
> --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/ClangFormatS...
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.
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?
I thought GP was saying "that's it" as in, "no more discussions about it" not "that's all it can do".
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?
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.
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.
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?
Not the OP, but like any other formatter where choice is involved: You pick one and go with it. See: Black for Python.
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.
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.
How is NPM more reliable or easy to use than rubygems? In my opinion Rubygems (with bundler) was the gold standard, and maybe now Cargo (Rust) or Stackage (Haskell) has stolen its crown.
Python package management is a drama, but I've heard Java developers defend their system, forgot if it was maven or gradle.
My main issue with NPM was belatedly solved when Yarn came out. The whole node_modules thing makes me consider it inferior to the others I mentioned, but I'm not sure it can be called a problem.
Python package management is a drama, but I've heard Java developers defend their system, forgot if it was maven or gradle.
My main issue with NPM was belatedly solved when Yarn came out. The whole node_modules thing makes me consider it inferior to the others I mentioned, but I'm not sure it can be called a problem.
Well one easy point is that rubygem doesn't allow easy local installations. Heck it doesn't even allow specifying all your dependencies — you have to use Bundler for that.
More anecdotally, I've had bad experiences with upgrades, though admittedly, the fact that Windows support is a second-class citizen in many popular gems might have been part of that.
More anecdotally, I've had bad experiences with upgrades, though admittedly, the fact that Windows support is a second-class citizen in many popular gems might have been part of that.
My main complaint about npm/yarn is that they keep the library code in the project dir and only keep the exact versions and packages that you are using so every time you switch branch you constantly have to run yarn to get the right package versions unlike with ruby gems where there is a folder outside of the project dir which contains a cache of everything you have downloaded and it all just works after branch switches.
Yarn Plug n Play tries to address this and other problems with node_modules such as heavy and deep trees of dependencies that fill up your computer for each project. It generates a .pnp.js file that tells Yarn where packages are located, so they can effectively be installed once and used in multiple projects.
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.
Won't this allow anyone with write access to the source code repository to publish a package? Seems just one extra layer of indirection.
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%
The old way had risk at two steps and now it's reduced 50%
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?
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?
Since most source code will be maintained via Git, there's almost no security at all, since you can easily rewrite Git history.
Well. Depends, if your package Version links to a commit hash, you should be rather secure. One could delete it but not overwrite it as easily.
One could presumably push a new version, linked to a commit that contained (directly or as an ascendant) some malicious code.
Oh. There are multiple problems:
1. There is no way to define deployment tokens per package. If you have an organization and want to deploy via CI/CD this can be problematic. If one token is leaked, it affects all packages
2. You cannot enforce 2FA for accounts in organization. So you also have problems if you don’t use CD.
These two problems could be addressed by the registry, the other’s are more of UX Gaps.
3. It is not easy to verify that a package contains the thing that is checked into source. We make it arguably harder by transpiling, etc.
4. It is not widely known how to use npmignore. Often packages contain unnecessary things like all of their documentation website or big images or tests. There could be better UX around that when you create packages or explore packages. The amount of temporary files published by an author in packages is just crazy.
These are the problems from the top of my head, I am sure that I could come up with more. It doesn’t mean that other package managers are better or that NPM is bad, but there is room for betterment.
1. There is no way to define deployment tokens per package. If you have an organization and want to deploy via CI/CD this can be problematic. If one token is leaked, it affects all packages
2. You cannot enforce 2FA for accounts in organization. So you also have problems if you don’t use CD.
These two problems could be addressed by the registry, the other’s are more of UX Gaps.
3. It is not easy to verify that a package contains the thing that is checked into source. We make it arguably harder by transpiling, etc.
4. It is not widely known how to use npmignore. Often packages contain unnecessary things like all of their documentation website or big images or tests. There could be better UX around that when you create packages or explore packages. The amount of temporary files published by an author in packages is just crazy.
These are the problems from the top of my head, I am sure that I could come up with more. It doesn’t mean that other package managers are better or that NPM is bad, but there is room for betterment.
If I can give one advice to dev tool makers, it'll be this: Do not build an IDE.
People are attached to IDEs like no other tool; they won't leave their customizations, key bindings, themes and switch to an unproven alternative. This isn't true all the time, but holds 99.9% of the time.
Also, despite being fairly familiar with the JS ecosystem I am unable to make out what Pika does from the landing page. You probably need to do a better job of explaining the product.
People are attached to IDEs like no other tool; they won't leave their customizations, key bindings, themes and switch to an unproven alternative. This isn't true all the time, but holds 99.9% of the time.
Also, despite being fairly familiar with the JS ecosystem I am unable to make out what Pika does from the landing page. You probably need to do a better job of explaining the product.
> I am unable to make out what Pika does from the landing page
This seemed fairly succinct:
> Pika is a new kind of package registry for the modern web
Not sure what "Universal JavaScript" means though, and I don't understand why a registry would need an IDE.
This seemed fairly succinct:
> Pika is a new kind of package registry for the modern web
Not sure what "Universal JavaScript" means though, and I don't understand why a registry would need an IDE.
What is “modern web” here? That can mean so many things.
They explain it right after the "modern web" phrase:
> 100% ESM
Here's some additional info: https://www.pika.dev/about
> 100% ESM
Here's some additional info: https://www.pika.dev/about
If the programming language of the day doesn't come with IDE support, even if a clunky one, I won't bother much with it beyond a couple of weekends to try out what it brings new to world of programming.
Same. I'd love, for example, to try out Raku/Perl 6, but I'm no longer interested in fiddling with VSCode or Vim configurations for hours just to get a mediocre debugger running. (This is not a complaint, I definitely do not feel I deserve anything for free.)
Perhaps you'd be pleasantly surprised the Raku IDE (Comma) has a free community edition, with excellent debugging capabilities: https://commaide.com
That's great! Can the commercial edition be used beyond the 12 months?
I'm going to go the other way on this. I like this idea, but I can see it's not for everyone.
I like to do some Javascript coding with my son on his Chromebook, and having a development environment is a hard problem for us to solve for some reason.
Having a webpage that just spins up VSCode and allows us to publish and test in a registry might be just what we need, no?
I like to do some Javascript coding with my son on his Chromebook, and having a development environment is a hard problem for us to solve for some reason.
Having a webpage that just spins up VSCode and allows us to publish and test in a registry might be just what we need, no?
This website is incredibly confusing and hand-wavy, but from what I've read in the past about Pika, I believe (though I had trouble finding this clearly stated) its key feature is automatic conversion of third-party JavaScript modules to the ES6 (here referred to as ESM) module syntax.
For those who aren't familiar, JavaScript has two distinct module syntaxes (and several variations on those). Nodejs brought its own when it came on the scene, and then later browsers standardized on a new one for the web. The two are incompatible in some pretty nasty ways (the former is a runtime function, the latter is fully static). So standard practice is to use a bundler like Webpack or Browserify to concatenate your code and all its dependencies into a single JS file (with modules being properly scoped, artificially, through functions scopes and other tricks) for use in web browsers. Basically, this allows browsers to avoid dealing with however all your modules may import each other; you can even mix both syntaxes in one project. The browser just sees one big file.
The problem is, a) this makes it virtually impossible to use any dependencies from NPM on the front-end without a bundler, which means a minimum required amount of configuration and tooling, and b) you lose out on some potential caching benefits because files that may not change much can't be distinguished.
So why doesn't everyone just use the new modules syntax so that code can be loaded in the browser, as separate modules, without bundling? Because if even a single one of your NPM dependencies is still in the other syntax, you're up a creek. It's like the IPv6 problem: until everyone has it, nobody does.
So projects like (I think) Pika have cropped up to try and address this. If it really does auto-convert packages to the new modules syntax, that eliminates the biggest reason to use build tooling in a modern JS project. You could theoretically get away with having no build process at all.
For those who aren't familiar, JavaScript has two distinct module syntaxes (and several variations on those). Nodejs brought its own when it came on the scene, and then later browsers standardized on a new one for the web. The two are incompatible in some pretty nasty ways (the former is a runtime function, the latter is fully static). So standard practice is to use a bundler like Webpack or Browserify to concatenate your code and all its dependencies into a single JS file (with modules being properly scoped, artificially, through functions scopes and other tricks) for use in web browsers. Basically, this allows browsers to avoid dealing with however all your modules may import each other; you can even mix both syntaxes in one project. The browser just sees one big file.
The problem is, a) this makes it virtually impossible to use any dependencies from NPM on the front-end without a bundler, which means a minimum required amount of configuration and tooling, and b) you lose out on some potential caching benefits because files that may not change much can't be distinguished.
So why doesn't everyone just use the new modules syntax so that code can be loaded in the browser, as separate modules, without bundling? Because if even a single one of your NPM dependencies is still in the other syntax, you're up a creek. It's like the IPv6 problem: until everyone has it, nobody does.
So projects like (I think) Pika have cropped up to try and address this. If it really does auto-convert packages to the new modules syntax, that eliminates the biggest reason to use build tooling in a modern JS project. You could theoretically get away with having no build process at all.
For those wondering what's wrong with npm, I can recommend this C J Silverio talk https://www.youtube.com/watch?v=MO8hZlgK5zc
Sadly, as others have noted, this Pika thing does not quite address these issues.
Sadly, as others have noted, this Pika thing does not quite address these issues.
This looks like something designed to be paid when early access is over? I thought Visual Studio Code's extension API was so extensive by now that something like this could be delivered as an extension instead.
While this seems to be an horrible attempt to replace NPM, how are the other attempts going?
Totally off-topic but, is there a word for this style of marketing copy/design language with lots of deep blues, rounded edges, primary colors and geometric shapes? Atlassian and Digital ocean use something very similar.
Flat design I'd say is the closest, although there's a ton of ways you could describe this. I'd also describe it as minimalist + a strong focus on readable typography with space to "breathe". Other sites like Digital Ocean have a great focus on simple iconography that enhances their message.
All-in-all I love that design trends have gone this direction as I think it's a friendlier and more efficient means to convey information =)
Years ago skeuomorphism was a popular trend which is to try to make things 3D representing real-world objects (buttons, dials, etc). Although it's still highly prevalent in UI design, we've really backed off of the trend. A great example of this is early vs. current iOS. I mention this because there's a ton of great "skeuomorphism vs flat design" stuff out there discussing the ethos of sites like this.
All-in-all I love that design trends have gone this direction as I think it's a friendlier and more efficient means to convey information =)
Years ago skeuomorphism was a popular trend which is to try to make things 3D representing real-world objects (buttons, dials, etc). Although it's still highly prevalent in UI design, we've really backed off of the trend. A great example of this is early vs. current iOS. I mention this because there's a ton of great "skeuomorphism vs flat design" stuff out there discussing the ethos of sites like this.
toddler style http://jollo.org/LNT/public/nursery.html
Stripe uses something similar too. I'd say it's almost a "round" version of material design.
It is present in the artwork too. Solid block colours and focus on geometric shapes. There are varients too (Facebook and Google do something similar, but their UX controls are sharper, but artwork similar design to this).
I think it's just a current trend in the SaaS world. Search for "SaaS website templates" and you'll find most of them have this same style.
It is present in the artwork too. Solid block colours and focus on geometric shapes. There are varients too (Facebook and Google do something similar, but their UX controls are sharper, but artwork similar design to this).
I think it's just a current trend in the SaaS world. Search for "SaaS website templates" and you'll find most of them have this same style.
I don’t mean to be snarky, but when seeing “make our neat package registry easy to use we wrote our own custom IDE for you to develop in,” I can’t help but think this project has jumped the shark.
Does Pika really expect devs to be so drawn to their package registry that they want to write in Pika Code instead of their existing editor of choice? Is publishing packages in JavaScript really that hard?
Does Pika really expect devs to be so drawn to their package registry that they want to write in Pika Code instead of their existing editor of choice? Is publishing packages in JavaScript really that hard?
If there was an extension for VSCode, maybe I'll consider using it.
But using your fork of it instead? Not a chance.
But using your fork of it instead? Not a chance.
I just don't understand dumping my entire development environment to solve one of the easier parts of package development.
I think the whole point of Pika was to not require a complex local development environment for coding websites. Installing a bunch of stuff is probably the #1 or #2 main complaint about modern frontend and a huge roadblock for newbies.
By using their CDN you can already make pages and apps with just a text editor, without node, npm, webpack, etc.
I think it makes sense for them to try to improve the experience of package creation and publishing too.
By using their CDN you can already make pages and apps with just a text editor, without node, npm, webpack, etc.
I think it makes sense for them to try to improve the experience of package creation and publishing too.
Why would those hypothetical newbies need to publish packages? That’s not something you should care about before quite some time when you’re learning a language.
Or is the idea to have a registry full of tutorial packages?
Or is the idea to have a registry full of tutorial packages?
[deleted]
From their about page...
> Pika is building a world where third-party libraries can be loaded, cached, and shared across sites.
Aren't most browsers disabling/about to disable cross-origin caching?
> Pika is building a world where third-party libraries can be loaded, cached, and shared across sites.
Aren't most browsers disabling/about to disable cross-origin caching?
It was rarely useful anyway. I saw some stats showing even with jQuery it was extremely unlikely users already had a copy of the version of jQuery from the same CDN cached.
Wasn’t that the point of Google sharing a copy of jquery for everyone?
> Aren't most browsers disabling/about to disable cross-origin caching?
Are they?
Are they?
Sorry, should have included a source link: https://news.ycombinator.com/item?id=21429621
Their about page[0] is interesting.
> "Pika is building a world where third-party libraries can be loaded, cached, and shared across sites" ... "With ESM and cross-origin caching, we can create a world where sites can share cached dependencies."
This is an interesting angle on a package registry. The goal seems difficult to achieve as well since the common web cache as we know it is dying[1]. It seems like we'd need some sort of "dependency" support for web browsers if we'd ever want to achieve it.
[0]: https://www.pika.dev/about
[1]: https://news.ycombinator.com/item?id=21429621
> "Pika is building a world where third-party libraries can be loaded, cached, and shared across sites" ... "With ESM and cross-origin caching, we can create a world where sites can share cached dependencies."
This is an interesting angle on a package registry. The goal seems difficult to achieve as well since the common web cache as we know it is dying[1]. It seems like we'd need some sort of "dependency" support for web browsers if we'd ever want to achieve it.
[0]: https://www.pika.dev/about
[1]: https://news.ycombinator.com/item?id=21429621
If this handled the "build & config" of publishing packages and made the whole process effectively 0-config, I could see myself using it. But there's a lot here that I don't want.
With GitHub templates and npm’s init/create packages you already have options without having to use an editor.
Examples:
Examples:
npm init esm
npm init react-app
I think the name is really bad in Brazilian Portuguese. Here "pika"* is a slang for dick. At the same time, it is still the sound Pikachu makes ("pika pika"). So maybe there is no problem.
* I don't know about European Portuguese. The correct spelling for the slang would be "pica", but both have the same pronunciation.
* I don't know about European Portuguese. The correct spelling for the slang would be "pica", but both have the same pronunciation.
I don't know why but someone edited my comment. The original had 2 footnotes which were combined into one. Now it is ambiguous. Thank you for your disservice.
It's definitely a Pikachu call-out. See the mouse logo and the lightning favico.
I believe that "mouse" may be a Pika, a real animal.
https://en.m.wikipedia.org/wiki/Pika
https://en.m.wikipedia.org/wiki/Pika
The homepage looks like it's written for 5 year olds. 100pt font and piles of whitespace do not convey information effectively.
Also the only thing I can see without scrolling down is a "give me your email" box. Not a good sign.
Also the only thing I can see without scrolling down is a "give me your email" box. Not a good sign.
>For this new ecosystem to work, we needed a consistent, universal dev experience for every package on the registry.
That's the most absurd sentence thing I've seen in awhile, editing is orthogonal to package management. But others have that thread covered. This got my attention:
> Pika publishes each package directly from source, so malicious or hacked authors can't skip code review or sneak malicious code unnoticed into the registry.
I don't see how injecting yourself in the middle solves the problem, since exfiltrating data in the background from a downstream app is both necessary for some services and hard to identify as "bad".
What I'd like to see in a registry is a registration fee per project (or pay per publish), non-anonymous registration (provide a government issued ID and mandatory 2FA), delayed deployment after publishing, and aggressive but open auditing. Plus org/user namespacing.
Basically if you have an environment where a bad actor has to pay money, steal someone's identity, and takes awhile before they can even verify their attack has been successful - you'll cover a huge chunk of the attack surface area.
That's the most absurd sentence thing I've seen in awhile, editing is orthogonal to package management. But others have that thread covered. This got my attention:
> Pika publishes each package directly from source, so malicious or hacked authors can't skip code review or sneak malicious code unnoticed into the registry.
I don't see how injecting yourself in the middle solves the problem, since exfiltrating data in the background from a downstream app is both necessary for some services and hard to identify as "bad".
What I'd like to see in a registry is a registration fee per project (or pay per publish), non-anonymous registration (provide a government issued ID and mandatory 2FA), delayed deployment after publishing, and aggressive but open auditing. Plus org/user namespacing.
Basically if you have an environment where a bad actor has to pay money, steal someone's identity, and takes awhile before they can even verify their attack has been successful - you'll cover a huge chunk of the attack surface area.
There is a gaping hole in the middle of this whole setup and it's that most actors are good actors and you're now demanding them to pay money. Furthermore, you're asking them to pay money while it gives them no benefit, it benefits third parties. As a publisher, I do not care if people who use my code trust me — if they don't, they don't have to use the code, I have lost nothing. There is no incentive for any package maintainers to join this endeavour. Asking me to provide real-world ID to pay the registrar money? Never going to happen as long as there's a free alternative without the additional constraints.
Raising the barrier to entry can tend to raise the quality of the ecosystem. I can also think of some incentive structures where the money that you pay to publish also helps you get traction/publicity, or to have a system where the top N packages get N% of the pool of money each month.
As for requiring real-world ID to spend money, why are you averse to that? AirBNB does that, your landlord does it, your bank does it. Does your employer do business with people anonymously? I think the bounds of privacy stop once you start shipping product to the world. If you want to remain anonymous, fine, go to an untrusted distribution channel where your code ca remain. If you want people to trust you, put some skin in the game.
As for requiring real-world ID to spend money, why are you averse to that? AirBNB does that, your landlord does it, your bank does it. Does your employer do business with people anonymously? I think the bounds of privacy stop once you start shipping product to the world. If you want to remain anonymous, fine, go to an untrusted distribution channel where your code ca remain. If you want people to trust you, put some skin in the game.
None of the examples you've made are appealing to me as an OSS developer. There is no incentive for me to increase publicity — what would it give me? If anything, having a lot of users is annoying: you get irrelevant PRs which are out of scope, beginner users submitting bug reports that are actually bugs in their own code, etc etc.
Your second point is the exact opposite of what most OSS developers want. By and far, most OSS projects are small components that end up somewhere down the dependency tree. This means someone else (a-la React) would get the money while leaving smaller dependencies (a-la string utils) unfunded. This is the polar opposite of what maintainers want.
Your last point of wanting trust is a straw-man. I already made it clear in my previous reply: as an OSS developer, I do not care if people trust my code. There is simply no incentive for me to care about it. People consuming my packages reasonably do want some sort of validation, but that's their desire, not mine, so why would I pay for that?
Your second point is the exact opposite of what most OSS developers want. By and far, most OSS projects are small components that end up somewhere down the dependency tree. This means someone else (a-la React) would get the money while leaving smaller dependencies (a-la string utils) unfunded. This is the polar opposite of what maintainers want.
Your last point of wanting trust is a straw-man. I already made it clear in my previous reply: as an OSS developer, I do not care if people trust my code. There is simply no incentive for me to care about it. People consuming my packages reasonably do want some sort of validation, but that's their desire, not mine, so why would I pay for that?
I don't think I would pay either. But then the question becomes: Why do you publish your software? Why not just keep it all to yourself?
If you have some incentive to share your code I assume it is you want your users to have and use your code. If you want them to use your code you want them to be able to trust that code too.
If you have some incentive to share your code I assume it is you want your users to have and use your code. If you want them to use your code you want them to be able to trust that code too.
> Why do you publish your software? Why not just keep it all to yourself?
Because that's how open source works? People publish stuff somewhere and others can use it. Explicitly no warranties are made. Anyone who uses it does so at their own risk.
> If you want them to use your code you want them to be able to trust that code too.
Trust doesn't have to be paid for in a walled garden model. People can use my code because they audited it and found that it's good. Or they could just use it because they know my reputation and trust it.
Because that's how open source works? People publish stuff somewhere and others can use it. Explicitly no warranties are made. Anyone who uses it does so at their own risk.
> If you want them to use your code you want them to be able to trust that code too.
Trust doesn't have to be paid for in a walled garden model. People can use my code because they audited it and found that it's good. Or they could just use it because they know my reputation and trust it.
> People publish stuff somewhere and others can use it.
Definitely. My question was "Why do they do it?". Nothing forces you to publish it. So there must be a reason why you do that. I assume it is because you want other people to use your software, for whatever reason.
So if you want people to use your software surely you want your software to be of high quality, which includes that people can know it is of high quality, which is where validation might help.
Whether you should pay for validation is a different question, I'm not saying you should.
Definitely. My question was "Why do they do it?". Nothing forces you to publish it. So there must be a reason why you do that. I assume it is because you want other people to use your software, for whatever reason.
So if you want people to use your software surely you want your software to be of high quality, which includes that people can know it is of high quality, which is where validation might help.
Whether you should pay for validation is a different question, I'm not saying you should.
You've made a couple of incorrect assumptions here.
> I assume it is because you want other people to use your software, for whatever reason.
No–as an OSS publisher I just want to make it possible for other people to use it. I don't necessarily have to want them to use it.
> ...surely you want your software to be of high quality
Again, not necessarily. It's a mix of factors–how much time and energy I have, how important the code is to me, whether I actually do want others to use it, etc. But there's nothing inherent in publishing OSS that says it has to be high-quality.
> I assume it is because you want other people to use your software, for whatever reason.
No–as an OSS publisher I just want to make it possible for other people to use it. I don't necessarily have to want them to use it.
> ...surely you want your software to be of high quality
Again, not necessarily. It's a mix of factors–how much time and energy I have, how important the code is to me, whether I actually do want others to use it, etc. But there's nothing inherent in publishing OSS that says it has to be high-quality.
That sounds like paying for exposure, and more downloads of an open-source project usually just means more work for the maintainer.
The problem with IDs and paying for registration is that this is specifically not a business, unless you're talking about a private registry that users also have to pay to consume.
The problem with IDs and paying for registration is that this is specifically not a business, unless you're talking about a private registry that users also have to pay to consume.
> Basically if you have an environment where a bad actor has to pay money, steal someone's identity, and takes awhile before they can even verify their attack has been successful - you'll cover a huge chunk of the attack surface area.
If you have an environment where a good actor has to pay money, provide their passport name with proof of identity, and has to put up with artificial deployment delays, I think you'll miss out on a huge chunk of good actors.
I'm not convinced that it's possible to outsource your trust and audit decisions to some third-party system. We should be scaling at the speed of actual human trust, not giving up our privacy to companies or our security to randos.
If you have an environment where a good actor has to pay money, provide their passport name with proof of identity, and has to put up with artificial deployment delays, I think you'll miss out on a huge chunk of good actors.
I'm not convinced that it's possible to outsource your trust and audit decisions to some third-party system. We should be scaling at the speed of actual human trust, not giving up our privacy to companies or our security to randos.
I would add: and bad actors would not be stopped by this, it is easy (and cheap) nowadays to buy identity with document scans enough to pass verification in payment systems. I doubt that any package registry could implement more stringent checks.
And a fee is just a small bump in the way of bad actors that would like to monetize their misdeeds.
And a fee is just a small bump in the way of bad actors that would like to monetize their misdeeds.
There's plenty of places/ways to distribute software anonymously. And depending on software from an anonymous identity with no trust that the registry verified who they were or if subsequent publications came from the same entity is an attack vector.
There is a time and place for anonymity, but I don't think a dependency registry is one of them (most of the time). And I think if you're going to make a new registry, such verification is a way to make yourself different.
There is a time and place for anonymity, but I don't think a dependency registry is one of them (most of the time). And I think if you're going to make a new registry, such verification is a way to make yourself different.
> if subsequent publications came from the same entity
The way you do that is by having signed packages. Gov IDs don't help with that, unless the registry verified the ID every time you published an update, which is impractical (unless you have a smart ID card, but most governments don't issue those).
The way you do that is by having signed packages. Gov IDs don't help with that, unless the registry verified the ID every time you published an update, which is impractical (unless you have a smart ID card, but most governments don't issue those).
A custom JavasScript-DSL for this seems to conflict with established CommonJS conventions for browser-packages/assets distributed on npm (ie. to use "browser" instead or in addition to "main" entries in package.json), and also with ES6 modules ("esm").
Seeing a new package manager makes me feel uneasy! Although NPM is not perfect, being able to NPM i all the things is nice, now that bower is defacto dead and you just use webpack instead. But if this takes off there will be choice again. Choice = JS fatigue!
Why not yarn? That’s been around a really long time to give you fatigue.
It won't. It requires you to use a custom editor.
It does not. The registry is completely separate from the code editor.
The problems Pika aims to solve don't sound like registry problems, and I think we could run into trouble as a consequence. For example, I've written code where I ES6 import an SVG file that, using webpack loaders, automatically becomes a React component.
A tool like Pika isn't going to understand that without making broad assumptions of my project's structure. This is more than just, oh "Do I need ES Modules or Common JS?" or "That file needs to transpiled since it uses the spread operator, and I happen to be rendering on IE 11, which doesn't support that."
In other words, I find this to be an interesting solution, but not something I'd feel comfortable with in enterprise-grade applications.
Just learn how bundlers and transpilers work. It's going to be easier to do that, then understand why Pika won't do what you need it to, having to go through yet another layer of abstraction. I've been disappointed by tools in the past that try to abstract away the "difficult" parts of maintaining a webpack.config.js and babel.config.js file. I truly believe it is more beneficial for developers to learn these things, instead of trying to be ignorant of them and then fighting with a tool like Pika or a toolkit that doesn't meet your needs.
Choose for yourself the better choice, and make your own toolkit: https://kentcdodds.com/blog/concerning-toolkits
A tool like Pika isn't going to understand that without making broad assumptions of my project's structure. This is more than just, oh "Do I need ES Modules or Common JS?" or "That file needs to transpiled since it uses the spread operator, and I happen to be rendering on IE 11, which doesn't support that."
In other words, I find this to be an interesting solution, but not something I'd feel comfortable with in enterprise-grade applications.
Just learn how bundlers and transpilers work. It's going to be easier to do that, then understand why Pika won't do what you need it to, having to go through yet another layer of abstraction. I've been disappointed by tools in the past that try to abstract away the "difficult" parts of maintaining a webpack.config.js and babel.config.js file. I truly believe it is more beneficial for developers to learn these things, instead of trying to be ignorant of them and then fighting with a tool like Pika or a toolkit that doesn't meet your needs.
Choose for yourself the better choice, and make your own toolkit: https://kentcdodds.com/blog/concerning-toolkits
How can I use this? I see stuff like importing directly from a CDN? What does that mean? I could just call `import` in my source JavaScript without transpiling? I also see `npm install` stuff, so what's the difference?
I'm interested in importing packages directly instead of transpiling stuff in some cases, but I don't see how would that work.
I'm interested in importing packages directly instead of transpiling stuff in some cases, but I don't see how would that work.
Ok, got it: https://www.pika.dev/cdn
I'll start using this thing.
I'll start using this thing.
Pika code has some nice features. I don't see myself switching away from PHPStorm/Visual Studio Code but the quick start feature seems like a great addition.
While using basic imports instead of a build step is nice, unfortunately most projects of any size or complexity end up requiring a build stage for components, css, static assets, optimization for the non-modern browsers and more.
It seems like the niche served by a package manager/cdn that serves native ESM modules is rather small.
The code editor seems unnecessary too, but it's built on VSCode so it can probably be repurposed into an extension easily. Better tools for publishing packages are needed though, and I like how it helps setup a modern environment for creating packages.
It seems like the niche served by a package manager/cdn that serves native ESM modules is rather small.
The code editor seems unnecessary too, but it's built on VSCode so it can probably be repurposed into an extension easily. Better tools for publishing packages are needed though, and I like how it helps setup a modern environment for creating packages.
I'm not really fond of the fact that the "About Us" page doesn't actually say anything about them. Who are you and why should I trust you?
Serious question: What does this provide that unpkg doesn't?
Modules on the web will have a hard time due to:
* Not good enough HTTP2 support in browsers. Browser will for example download pushed files twice, once when pushed, then again when imported, and not caching the pushed files.
* Many developers prefer to brake their code up into small files, meaning there will be a lot of hops until the entire dependency tree has been resolved.
* There is no standard for lazy loading, meaning the user need to download everything, even if only 5% is actually required.
As much as a hate bundlers, and would like to see more code moduleability on the web, bundlers get the job done using code splitting, deduplication etc.
* Not good enough HTTP2 support in browsers. Browser will for example download pushed files twice, once when pushed, then again when imported, and not caching the pushed files.
* Many developers prefer to brake their code up into small files, meaning there will be a lot of hops until the entire dependency tree has been resolved.
* There is no standard for lazy loading, meaning the user need to download everything, even if only 5% is actually required.
As much as a hate bundlers, and would like to see more code moduleability on the web, bundlers get the job done using code splitting, deduplication etc.
While I don’t think I’ll be able to use Pika, it’s always good to see novel dev tools being released.
I’m keen to see how Pika Code improves the end to end dev experience by presumably being tightly integrated with deployment. Remind me of Dark in a way.
I’m keen to see how Pika Code improves the end to end dev experience by presumably being tightly integrated with deployment. Remind me of Dark in a way.
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.