jsr-io / jsr Goto Github PK

Not sure if this is an issue, or if these sections are intended to scroll at some point in the future.

(this is particularly obvious on Windows which makes scroll bars so much uglier than macOS)

suggest changing to overflow-y-auto or removing the overflow altogether

The user should receive an email notification when a new version of the package is published.

They should be able to opt out from / opt into these notifications in their account page, per scope. There should also be the option to disable notifications for all scopes (including ones joined in the future).

Clicking the AdultContentPref symbol on this page https://jsr.io/@mary/bluesky-client/doc leads to a 404

When the package has a table in it, the layout breaks on mobile

https://jsr.io/@orama/orama/score

https://jsr.io/@cyclonedx/[email protected]

Dear jsr maintainers,

Greetings from the cnpm team, the provider of stable and free npm registry package mirror services in China, including the frontend at https://npmmirror.com/ and the registry at https://registry.npmmirror.com/.

After testing, we have found that we cannot directly access the npm.jsr.io content within mainland China. In order to provide better services in collaboration with jsr in the future, we would like to request mirror synchronization capabilities similar to those offered by npm registry.

We rely on the changesStream interface provided by npm registry to deliver streaming version change information at https://replicate.npmjs.com/_changes.

Additionally, for frontend display purposes, we also hope to provide manifest interfaces to showcase metadata information.

Looking forward to your response.

See https://jsr.io/@mary/bluesky-client/doc

Each package / package version should have a license field. This field should be a SPDX ID of a license.

This license should be visible via the API and UI, and could be useful for auditing purposes.

We should sniff the LICENSE file (like GitHub does) to populate this field. There should be a fallback where you can explicitly set the license SPDX ID via either a field in the package settings, or via a directive in the license file.

Requires denoland/deno_doc#377

Here to view the bottom of the sidebar, I need to scroll the viewport (the page), and the sidebar all the way to the bottom. This makes no sense, because the page content is small enough to fit on the page without the viewport having to scroll.

The current behaviour only made sense if the content was larger than the viewport (which it is not).

Not fixed by #46 it seems.

Just reproduced with denobot.

It would be nice if the symbol search took up the whole screen and occurred when the search bar has contents. Then you can exit out of the search by clearing the search bar (similar to how docs.rs works)

Currently the package navigation takes up a lot of space in mobile view and users have to scroll quite a bit to see any of the content.

I believe we should explore something like this where the navigation tabs get a bit smaller, hide or shrink any chips, and limit the displayed nav items to 3-4 and put the rest in a clickable menu. This mirrors the experience users have on github so it should be a pretty familiar mobile pattern to this audience.

Rough example of suggested change

I only use GitHub mostly for third-party contributions at this point, with my own code repositories being hosted somewhere else (right now, Codeberg)

While I wouldn't be able to take advantage of functionalities like provenance, I would expect being able to link to my actual repositories at the very least, where people can go to for bug tracking etc

Currently, there is no link to this repo on the https://jsr.io website. I found this repo by clicking the "Edit this page on GitHub" link.

Update: I found this https://jsr.io/docs/faq#is-jsr-open-source

Maybe in the header, add a GitHub logo that links to https://github.com/jsr-io

Some of the queries in api/src/db/database.rs are very large which makes them hard to read.

We should use sqlx::query_file! macro and move large queries to separate files in api/src/db/queries/.

One drawback is that we will need to specify them as sqlx::query_file!("api/src/db/queries/<query_name>.sql") which will not make them clickable, but it's probably still better.

Once we do that, we should set up SQL formatting as well (eg. https://github.com/dprint/dprint-plugin-sql).

Only show the exporting module if it's not the main module. For the main module, show nothing.

JSR doesn't have the ability to emit JavaScript from TypeScript sources to serve browsers.

The JavaScript emitted should also be cached.

Example of TypeScript code from JSR https://jsr.io/@kwhinnery/yassify/1.0.0/mod.ts:

export function yassify(str: string): string {
  return `${str} 💅✨👑`;
}

At this moment, this code doesn't work.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>JSR in the Browsers</title>
</head>
<body>
  <script type="module">
    import { yassify } from "https:/jsr.io/@kwhinnery/[email protected]";

    alert(yassify("In the browser!"));
  </script>
</body>
</html>

Although doing similar with esm.sh works:

<script type="module">
  import { yassify } from "https://esm.sh/jsr/@kwhinnery/[email protected]";

  alert(yassify("In the browser!"));
</script>

The jsr.io website actually displays that

JSR is designed for TypeScript. You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility.
JSR packages are distributed as web-standard ECMAScript modules.

JSR should implement emitting and caching for browsers. It would be the ultimate JavaScript registry.

After going to /auth and approving publishing through the interactive flow in the CLI, we should navigate the user to an intermediate page where they can see the package progress, and once the package is published:

• if just one is being published, redirect to the package page
• if multiple are being published, show the list of published packages

It would be great if we could add support for rendering "alerts" syntax that's available recently in GitHub: https://github.com/orgs/community/discussions/16925

An example that uses this syntax is @badrap/valita. As shown in the screenshot below, this syntax is rendered with no decoration, which is okay but not ideal.

To support this syntax, we need to fix markdown parsing logic performed in the backend API server, which intenally calls deno_doc::html::jsdoc::markdown_to_html, and finally ending up with comrak crate as a markdown parser library. The problem is that this crate doesn't plan to support "alerts" syntax at least for the time being (see kivikakk/comrak#352). We need to come up with another solution here.

I've published my own package that makes use of auto-generated TypeScript declarations, however, the symbols listing page looks wrong

https://jsr.io/@mary/bluesky-client/doc

• The page isn't built to accommodate very long interface/type names resulting in horizontal overflows especially on mobile viewport
  
• There's some funny bug around Output that I can't tell exactly what caused it
  
• A lot of these symbols are actually contained inside a namespace, and therefore will 404 if you click the links

I can only assume this is because they're being referenced relatively, like so:

Someone uses pics in readme to add a bit style. Like:

Github handle html tag with size adjustment:

<img height="18" src="https://raw.githubusercontent.com/PKief/vscode-material-icon-theme/main/icons/deno.svg">

But JSR front end shows this pic streached to fullsize:

Is it ok?

A bit of a stretch goal, but it would be cool if these inputs supported auto completion:

Doesn't actually seem too tricky - we can make requests to GitHub from the API server using the users' own oauth tokens. This will return the list of orgs they have access to, and the public repos in those orgs.

I think that we can auto fix the majority of slow types diagnostics (missing return types, and explicit class types) by using TSC inference and then fixing up the source code with the explicit types gotten from TSC.

This is a bit of work, but would make supporting types in your package a matter of jsr publish --fix (or deno lint --fix). Right now the wall of slow types errors could be a bit daunting.

This would create an invite that is not bound to any specific GitHub user, and instead is valid for anyone who uses the invite link. This invite link would be sent to the invited user by email - they click on it, sign in with their GitHub account, and then accept the invite.

add search for https://jsr.io/docs

I'm trying to publish https://github.com/Mafalda-SFU/Remote-Mediasoup-client-mock on jsr.io, but I get an error about Package name cannot be longer than 20 characters. Although I can understand there's a limit on the length of a package for usability purposes, it should be an advice and not mandatory, specially if they are packages already published on npm, so we should have at least the same limits for compatibility purposes.

Current workflow:

1. deno publish
2. Visit to authorize publishing
3. Click "approve"
4. CLI detects that the version has already been published and prints

Skipping, already published <package>@<version>

It seems wrong that I have to authorize an action when it's known in advance that the action isn't possible to execute successfully. The CLI should already know that a conflicting version exists and bail out early.

Hi there,
great that you get forward.

I have a question because this project is new.
Will you implement support for json5 and the comment function in json?

Nodejs closed this issue: nodejs/node#40714
Npm will do when nodejs and js do something and locked the discussion: npm/feedback#56 (comment)

That is a usp for your project :)

Thanks for the attention.
Cheers

Markdown tables are allowed to run past the normal content window and thus bleed into the document navigation that appears on the right hand side for documents that use standard headers.

To publish with JSX, we need to take the JSX relevant config options from tsconfig.json / deno.json and put them into the source files via pragmas.

For example, when publishing this index.jsx file with this deno.json file:

import { renderToString } from "npm:preact-render-to-string";
console.log(renderToString(<div>jsx</div>));

{
  "compilerOptions": {
    "jsx": "react-jsx",
    "jsxImportSource": "npm:preact"
  }
}

emit this before publish:

/** @jsxRuntime automatic *//** @jsxImportSource npm:preact */
import { renderToString } from "npm:preact-render-to-string";
console.log(renderToString(<div>jsx</div>));

The order of the symbols in the document is flaky on every access.

e.g. https://jsr.io/@vcltk/ast/doc/~/Declaration

typealias first	namespace first

This issue may depend on deno_doc.

This should cut memory utilization drastically on frontend.

Hi, really cool project but I am facing one problem to publish my package to JSR : the limitation of 20 characters and the fact my plugin name is vite-plugin-browser-sync. I think I will not be alone with all vite-plugin- prefix 😄

Maybe increase a little bit? You don't need to go crazy like npm 😃

We already collect this information in GCP logs - we now need to aggregate & store it somewhere so we can display it.

Hi. Today I noticed an issue when trying to publish an existing npm package that has optional peer dependency on uWebSockets.js which is officially only published on Github.

• Reproduction: unjs/crossws#19
• Relavant issue: https://github.com/uNetworking/uWebSockets.js/issues/1026

package.json:

{
  "peerDependencies": {
    "uWebSockets.js": "*"
  },
  "peerDependenciesMeta": {
    "uWebSockets.js": {
      "optional": true
    }
  }
}

deno.json: (I guess it is not picked btw)

{
  "imports": {
    "uWebSockets.js": "https://esm.sh/gh/uNetworking/uWebSockets.js"
  }
}

Deno publish (1.41.1)

deno publish --dry-run
error: npm package 'uWebSockets.js' does not exist.

Hi, I tried JSR today and found an issue on documentation.

My package has a single default-exported function.

/**
 * ...
 */
export default function cloneJSON(value: JsonValue): JsonValue {
  // ...
}

I expected the name of this function was cloneJSON on the documentation.

import cloneJSON from "@rhy/fast-json-clone";

However it was listed as default actually.

import { default } from "@rhy/fast-json-clone";

When a default-exported function is named, the name should be respected in its documentation.

https://jsr.io/@rhy/fast-json-clone/doc/~/default

I’m wary of allowing other websites to have excessive permissions on GitHub. Is there some way of making it possible to publish packages without the “act on your behalf” permission?

Probably we should also have a little indicator in the search bar that you can press s to search. Like on the tailwind website:

Maybe also use Ctrl-K?

Hi! Thanks a lot for this initiative to democratize package management 🔥

I just ran into an issue with pnpm workspace in my package neodrag. IG I can work around it by publishing the built files from dist, but would be neat if jsr could handle workspace:* version

PuruVJ/neodrag#143

With our recent color updates there isn't much distinction between the security mode that is selected vs the one that isn't selected. This should be updated so the selected one is more clearly selected and the un-selected one is more clearly not selected (but selectable)

These should be clickable:

Understand this is vague, but I have no clue where to look, happy to provide any details you require to help out