Hello, this is Jessel from Private Ownership to Open Governance.
So first, Huawei, I'm Leo, soft engineer Dino working on Jessel, particularly
the dog generation aspect.
Yeah, I'm Luca.
I also work Dino.
I also do standards work on TC309, so on JavaScript itself.
And I work on various aspects, various web specs, like fetch.
Yeah.
So first off, what does Jessel say?
I mean, how many people here know what Jessel is?
A fair amount of what's there about a third?
How many people have used Jessel?
Half of that, okay, fair enough.
So Jessel is our modern JavaScript registry.
So similar to MPM, for example, that supports TypeScript after box.
So you don't need to transpile to JavaScript first.
You can just upload TypeScript directly.
And consumers of those packages can just import without problem.
But it does not replace MPM, it lives alongside it.
So you can, for example, use MPM dependencies in your Jessel packages.
And if works across different run times, be it Dino, no Jess, bun,
Cloud for workers, you name it.
As long as it supports Package Jason and no modules folder.
And yes, M.
Yeah, because that's all the thing.
Yes, M is required in Jessel.
You cannot use CJS.
We don't like it.
So, and it's completely open source in free.
So it's not like MPM that's close source.
It has like a pay tier if you want to do private packages.
It's completely open source in free.
And so why?
Well, complexity.
Poplishing to MPM is too complex.
I mean, as mentioned earlier, TypeScript just works with MPM.
You first have conference pilot generated DTS files, et cetera.
And it's just not a clean process.
And in terms of just setting that up, it's hours of work.
Yeah.
So you're export maps.
You're like dependencies.
You know, the difference between dependencies, peer dependencies,
optional dependencies, optional peer dependencies, like all these things.
No, you don't want to know.
Yeah.
And innovation.
Well, MPM really hasn't changed anything in the past years.
They don't add new features.
They don't really interact much with the community.
So that's why we want to change that.
And we have a quick question to the audience.
Like who of you knows what the last feature is that MPM shipped?
Raise your hand.
Go ahead.
Work spaces?
Good guess.
I mean, it's like about that age.
It's the little like blue TypeScript icon.
At the top left of the package that tells you whether a package has types.
That was like three years ago.
So.
And yeah.
I mean, we all know like the JavaScript ecosystem.
Oh, and you framework every day.
Well, so it's really, really fast.
But MPM is just holding back or not changing anything.
So yeah, we want to address that.
And well, our values, which unlike MPM is owned by Microsoft,
so it's completely open.
And so yeah, open source community and open governance are the core principles.
Again, we, for example, having the case of MPM,
it's just it's known that they don't really interact with the community.
They don't really care about issues in the community.
Like let's say there's a package that someone else should have,
but they don't transfer it.
There's been problems like that all over the place with MPM.
So these are things that we also try to address.
So I guess it's time of time.
Yeah.
I guess like better than us explaining it is just show you how it works.
So this is the JSON website.
JSON radio to start publishing a package.
You go here.
You sign in.
And you click publisher package.
I'm already signed in.
So I'm just going to go to a published package.
So this one interesting thing about JSON.
So unlike MPM, which has these top level packages,
that everybody can sort of squat.
JSON doesn't have this.
It JSON every package isn't a scope.
And you're limited with a number of scopes.
You can register.
So you can't like just register in the entire world.
And then get people to pay you to release those packages.
Right?
Like you cannot squat packages on JSON.
It's explicitly against our policy.
And if you do see someone do it.
Tell us.
Well, we'll fix it.
So I'm not going to create a new scope because I already have one.
But usually you can just click here and create one.
But I'm going to select an existing demos scope.
And I'll call it foster 2025.
Yes.
So we'll create the package.
What this will do is it will just like tell JSON.
Hey, I'm about to publish this package.
It'll give you some instructions for how to do it.
So you're going to get this little JSON file that just contains
the package name, the conversion of the package.
What license it is, and then an export field.
And the export field is not the same export field that you have in package
that's much simpler.
It does not support conditional exports.
You don't have to specify types in there.
You don't have to specify seed JS versus ESM.
All of these things, because JSON supports ESM.
And you can publish types out of the box.
So yeah, this is the short-hand syntax where we're just exporting mod.ts.
Leo's going to copy that into a repository.
So I have an empty directory here.
I'm just going to create a JSON.
And then we're going to just create a index.
Or what is it?
Mod.ts file.
No package JSON.
No TypeScript configuration.
Nothing.
Just a TypeScript file.
And start exporting something.
So let's write like a simple function.
I don't know adding numbers, I guess.
That's a good example.
We're going to take two arguments, A and B, return, A plus B.
And this is TypeScript.
So we can actually annotate this with types.
So you can do A is a number.
He is a number.
Returns a number.
I know.
Crazy, right?
And then let's also add some docs.
Because JSON can actually generate documentation automatically from your code.
And for this, we're just going to use the regular JSON docs syntax.
Yeah, I guess what does this function do add two numbers.
Yeah, at least.
This is the most popular package tomorrow.
I don't know.
We're going to go really all out documenting this year.
Yes.
Cool.
So yeah, that's about it.
So we have a package now.
Let's publish it.
So to publish it, you can either use the JSON RCLI.
You can use that through.
And actually, can you go back to the JSON website?
You can either publish with npxjs or publish.
Or whatever your favorite package manager is, or you can use, you know, publish.
It's built right into Dino.
I'm using your Dino installed.
You're considering you work there.
So maybe use Dino publish.
It's exactly the same thing.
So let's do that.
You know, publish.
And then here's another interesting thing you're going to see.
JSON does not have tokens.
That process to your local machine, because there's a lot of security vulnerabilities that come with that.
Namely, people can steal those tokens.
So when you publish locally, you actually interactively authorize publishing by clicking the link in the CLI.
It sends it to the website.
You click on approve.
And then it publishes.
And that way, we can make use of two factor authentication and all that kind of thing.
So now it's going to publish.
We're going to wait here for a second.
That was pretty fast.
And the package is published to JSON.
Okay, you can all see it now.
JSON.io slash at demo slash, fast in 2025.
No, Docs don't.
We don't have a read me.
And we don't have any documentation in the index of the module itself.
But we can look at the documentation for the ad function.
So if you hit the Docs tab, you'll immediately see these are all the exports from the module.
You see the documentation here that.
Leo wrote.
And if you click on the ad function, you'll see the parameters obviously the return type.
And then all the documentation that we wrote for those parameters.
Obviously, for an ad function, not so important.
But as you can imagine, this gets very useful if you have large packages.
And then on the right there, you can see how to import these packages.
So you can use this with all kinds of different things.
With Dino and PM, yarn, PM, bun.
We remember what option you chose there.
So if you, like, often use bun.
For example, you can select that while we show you the bun instructions.
But yeah, so what we're going to do now is just demonstrate that this is actually working.
You're just going to copy that second thing right there.
This doesn't actually require an installation step.
If you know it just works out of the box.
And I think you're just going to start a repule.
And import directly from this ad function.
I'm just sorry.
I'll download it.
You can have an ad function and let's hope it works.
It does.
Woo!
We can add numbers.
Cool.
Yeah.
So that's publishing.
If we have time at the end also you have the publishing or how to consume this in
MPM.
But the other really cool thing about JSR is that we score your package with some automatic metrics.
And you can use this to sort of judge from the search for example,
whether a package is like really something you want to be using.
For example, doesn't have documentation.
Does it have a description?
Does it mark which run times it uses all these things?
Score is currently 58.
We can improve this.
We don't have time though.
So we'll do this some other time.
This is probably going to impede us to being the number one package tomorrow.
But oh well.
Cool.
So let's move on to some other features.
Yeah.
Token was publishing.
I mentioned that before.
But actually we also do this from CI.
So you can publish directly from your CI machine without having to set up any tokens in that CI machine.
For example, on GitHub actions, there's OIDC tokens.
These are sort of a standard authentication mechanism coming from CI
Avengers that allows you to publish without having to configure any static tokens.
They can be leaked.
In JSR, you can just specify this is to get a repository.
I'm going to be publishing from.
And then add, you know, publish or JSR publish to your GitHub actions and
it just works.
You don't have to set up anything else.
Score provenance.
So when you publish, we publish a sort of manifest that describes what you've
published from where with what hash is into a public registry.
That is type of proof.
So you can actually see that any given package who was published by when it was
published where it was published from what repository it was published.
So you can sort of follow the supply chain to make sure that not some random person is
publishing something that they shouldn't have been.
And then the documentation generation, you saw that a second ago.
Yeah.
I mean, we just generate documentation for all the typeings and functions that you
export and try to make it as good looking as possible.
But now, the actual thing that the name of the title of the focus
governance.
Yeah.
So obviously, we cannot compete with NPM on the thing of open governance
if we don't have an open governance structure.
And so far, we haven't.
So far, JSR has been completely open source.
It's been like source.
This source has been available and we've been taking PRs from contributors.
And again, for both the backend, the CLI and sort of anything that is touched
by that.
But we now want to expand to actually have an open governance where we have
member, we have a board, a governance board, consisting of members from all kinds of
different companies in the JavaScript ecosystem that can control this without any
specific company having, like, undo influence over the project.
So yeah, why do we want to do this?
We don't, like, JavaScript itself is not controlled by a single company, right?
JavaScript is standardized in T339 in a standards group with many different
companies, all the browser vendors, many stakeholders of
JavaScript.
And we don't really want the registry that JavaScript
is used to be any different from that.
It should be controlled, not by one company, but by a group.
JavaScript implementations are also open source, like,
V8, JavaScript core, spider monkey, these are all open source.
So why shouldn't the registry be open source too?
And we've seen in the past that NPM being closed source is very
unfortunate.
It means there's no way for the community to force innovation other than
in package managers, we've seen this in package managers like when
the yarn came out NPM, the CLI got a lot better because
GitHub was forced to do something, but there has been no competition in the
actual registry space itself, so like the back end.
So GitHub hasn't been forced to innovate there.
Yeah, so JavaScript needs to be a source covered by the community and open
to innovation.
So the board members.
Evan, you?
Isaac Fluter?
James Snell?
This guy?
And Brian Del.
Yeah, Evan, you are the creator of V and of you.
You may know him.
He is currently starting a new startup called Voy0.
Isaac Fluter, the original creator of NPM.
Now, co-founder of Volt, which is a package manager,
tool for NPM.
That's not quite launched yet, but it's getting their
James Snell and Node.js, TSE members.
So this is the technical steering committee of Node.js.
And he's a principal engineer at CloudFlare.
Me already told you who I am.
And then Ryan Del, who is the original creator of Node.js,
and also the creator of you.
So what does this board actually do?
We oversee the thing that we want to do is move
JSR through a foundation, a foundation being something like
the Linux foundation or something like that.
And the board is going to figure out how this works.
So how this works in practice, obviously, but also figuring out
whether we need to split up our own foundation or whether we can move
to an existing foundation, like the Linux foundation,
or the, or, yeah, Open.js, for example,
we will set the general direction of the project.
This is not like the day-to-day operations of like,
what PR gets merged and what PR doesn't, but it's more like,
this is the direction we want to go.
So like, we don't want to support Common.js because of
these reasons.
Or maybe in the future, there's some new dialect of
JavaScript like TypeScript that we may want to support.
The board is the group that will decide this.
Yeah, the second thing is sort of that same.
We will obviously determine how the governance board evolves
and moving forward, like whether we need to add more members,
whether there's members that I don't know what to leave.
We will also establish a moderation group.
So another part of the problems with NPM is the fact that
moderation happens by GitHub and by Microsoft sort of with their own
policies that are not really public.
And it's very arbitrary, honestly.
And we will establish an open moderation group that anybody
from the community can join will be like voted into the group.
And they will determine what the moderation policy is,
and actually enforce the moderation.
So determining, for example, whether a package is actually squatting
or not, whether a package should be moved from one owner
to another because it is on maintain, things like that.
And then we will figure out how to actually do the day-to-day
of reviewing contributions to the project,
and then obviously how to do funding.
This is a very big question.
How do you publicly host what is effectively content delivery network
in an open source context, right?
This is like, you're having people download very large pieces
of code, essentially, from the internet.
Somebody has to pay for this.
And how exactly this works, we don't know.
Dino is in a state right now where we can absolutely pay for this,
and we are going to, and we're willing to.
But in the future, we will have to figure out whether this involves
other companies, also sponsoring JSR,
whether this involves us working with CDN vendors,
like CloudFlayer or Fastly to pay for bandwidth,
or whether this is something else entirely that we could do.
And we would be very interested to hear your thoughts on this.
Dr. Clarify on that, we also had a first meeting,
and just to quickly skip to one point is that there is
the discussion of operation cost, which we reviewed,
and networking being a notable expense, as Luca just mentioned.
And it was an interest from exploring cash and solution,
and CloudFlayer potentially supporting to help mitigate the cost.
So technically, we already potentially have CloudFlayer taking that over.
And then there was discussion about moving JSR,
to an open structure, just to make sure that it's actually independent,
and not just run by Dino, like it is currently.
Adoption trends were shared internally,
the need for better tracking of active usage,
and download metrics were noted,
and technical challenges were discussed.
Like meta-interability with MPM, being able to self-host,
having private packages, improved package manager support,
so being able to have better integration with the likes of MPM,
yarn, et cetera.
And enabling direct H2PS imports, which has been a relatively popular request,
being able to just import a JSR package in the browser we H2PS URL,
but that obviously opens the big concern of cost,
because then you're just turning into just the liver,
and that's not cheap.
Yeah.
So, any questions?
Yeah.
I certainly commend tenor of open source project.
What is my strategy if I want to support JSR,
like, but I still want to help MPM users,
to support it to the boss platform,
or like, this is a easy way to, from not users to use.
Ah, just like, what do you suggest for my intelligence of open source projects?
Very happy you asked this question.
Do you want to do the demo of importing from MPM?
Sure.
If it works.
The demo is here that we apparently have time for.
So, it's a great question.
Like, if you have an existing package,
that maybe is already a public MPM, how do you publish that to JSR?
So, you have two solutions.
Either you do a publish to both MPM and JSR.
You can do that.
That's perfectly reasonable.
But JSR actually supports people from,
like, with the MPM package manager or yarn,
or MPM importing your package.
And if you go to the website, Leo,
and we go to the site bar and click on,
use with MPM.
Awesome.
You can actually see here this MPX JSR ad.
Command.
So, I can just delete the package itself.
We don't need it anymore.
Just noise.
And I guess, do you need to create a package JSR?
No, no, no.
Yes.
Sure.
Oh.
Out of one package.
Yep.
You can see there's a no-module folder that has the package inside.
And this is sort of the MPM translation output of the package.
So, if you publish any package to MPM in TypeScript,
we will automatically translate two JavaScript for you for MPM users.
And users can just import it using JSX and MPM,
or sorry, MPX JSR, whatever.
And actually, in the future,
we're hoping to sort of have more native integration with package managers like MPM,
so that users can just specify a JSR colon something,
something in their dependencies rate in their package JSON,
and just have it installed out of the box.
Yeah, we'll see where that goes.
Does that answer your question?
Cool.
Anyone else?
Yes.
It's fine.
You can publish the package just now on JSR.
Thank you very much.
Yes.
All right.
Perfect.
Anyone else?
Publish a package suddenly?
Cool.
If you have any other questions, feel free to reach out to us.
You can join our weekly open working group meetings and office hours.
Ignore this dinner.co link.
We don't have a redirect service on JSR.
It's domain, but yeah, this is like an open meeting on discord,
where you can join every two weeks.
I think on Thursday.
And yeah, you can just chat with folks using JSR.
And yeah, if you want to try JSR yourself,
and if you want to contribute, or just see you look at the source code.
JSR.
That's how you're always slash JSR on GitHub.
Cool.
Thank you very much.