Use cases for non-typed developers

[toviszsolt]

trafficstars

I tried guys! I am trying really hard! 😁

Npm concept: time has proven that this is not the right approach.

Developers embed everything in packages as "distribution", when "distribution" should be the usable code, not the source code. Even in its smallest, compressed form. The repo with the source code is linked (in most of cases).

I have taken the time and the energy to learn and practice how to do it well on my part. Start a project → Setup rollup as bundler → build a dist version for CommonJS AND ES Modules AND TypeScript → Publish the dry necessary files only

I'm a JS developer, I hate TypeScript, no one is going to tell me that TypeScript is good, because I'll tell you to learn JS if you want to code in JS. And I also write the JSDoc in a separate file because it interferes with reading the code, just like TypeScript.

So guys, please find a place for people like me, and figure out how "Has docs for most symbols" challenge will be passed. 😎

The "Has provenance" challange I am able to solve. 👌

https://jsr.io/@toviszsolt/react-scrollspy

[sachaw]

You are able to consume JSR packages in vanilla JS projects just fine. Only ESM code is supported by design, let's not regress, the point is to let CJS and other obsolete module systems die.

[toviszsolt]

@sachaw

Has docs for most symbols At least 80% of the packages' symbols should have symbol documentation. Currently 0% of symbols are documented.

JSDoc in the separated d.ts file. 🧐

[lucacasonato]

Do you mean you'd like to upload .js files with accompanying .d.ts files? Or .js files containing /** @type */ TSDoc annotaitons?

[toviszsolt]

.js files with accompanying .d.ts files containing /** @type */ TSDoc

I'm linking the package again, because even though I've already linked it, no one seems to bother to look at the files. https://jsr.io/@toviszsolt/react-scrollspy/2.0.6/dist

[lucacasonato]

That is already supported, as long as you add // @ts-self-types="./react-scrollspy.d.ts" to the top of your JS file 👍

[toviszsolt]

@lucacasonato

Thanks you for your answer, but this is not possible. There cannot be the suggested comment. Any other solution?

[Klustre]

JSR supports and encourages publishing TypeScript source code rather than pairs of .js + .d.ts files. This allows JSR to provide more helpful auto-generated documentation, and helps provide improved auto-completion in editors.

From the docs

[TriMoon]

@toviszsolt

Thanks you for your answer, but this is not possible. There cannot be the suggested comment. Any other solution?

Maybe you could create a jsr.json that exports a TypeScript entry point who's only purpose is to import/export the real entry point plus import the types from your separate type definition file(s)? 🤔

Something similar to:

• jsr.json:

  {
    "name": "@....",
    "version": "major.minor.patch",
    "license": "CC-BY-NC-ND-4.0",
    "exports": "./jsr-entry.ts"
  }
  

• jsr-entry.ts:

  @import type {...} from "./types.ts";
  @import * from "./your-main-entry.js";
  @export * from "./your-main-entry.js";
  

---

I'm a JS developer, I hate TypeScript, no one is going to tell me that TypeScript is good, because I'll tell you to learn JS if you want to code in JS. And I also write the JSDoc in a separate file because it interferes with reading the code, just like TypeScript.

Although i can sympathize with what you say there, cause I'm still a non-TS / Pure-ES coder also. I honestly have to advise you to look into TS, cause it helps in coding with less bugs, or at least inline your JSDoc annotation's. If you like to see comment-free code you can always use a text filter 😜

You will be pleasantly surprised by what your IDE will catch while you code using types vs without types...