Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speeding up the JavaScript ecosystem – Isolated Declarations

marvinh.dev

Post reply on HN
Print view View original

21–30 of 57 posts

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#21

Post by austin-cheney »

rezonant wrote: post #17
austin-cheney wrote: post #15

Earlier quoted context omitted.

I write all my d.ts files manually. Maybe that’s the problem: people don’t know how to write TS, expect some software to do it for them, and then end up waiting hours on a build that should take 10 seconds.

This confuses me. You either write the d.ts manually before build, which only makes sense if you wrote the original code in JavaScript (not Typescript) or you write the source in Typescript and enable the declaration option in your tsconfig and the d.ts pops out in seconds along with your final JS output. Unless you are using transpileOnly, generating declarations will not make a few second build become a few hours--…

I write TypeScript projects in TypeScript from the start. If I have an existing JS project that needs to port to TypeScript then I will rewrite it entirely in TypeScript. Yes, that takes some small amount of time, but it’s never a complete rewrite. It’s mostly just minor syntax updates as the actual runtime should remain the same as validated by test automation.

I type everything I declare whether a primitive or not. My complex types like data structures, objects, and modules get typed as interfaces. I write them as I need them. I also have lint rules that check for missing type declarations.

Don’t over think any of this. None of this exists as an exercise in code masturbation. There are two immediate values to TS: warning on unintended type coercion and predictive rapid refactoring. So, just keep plan your software appropriately and keep everything simple.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#22

Post by seniorsassycat »

rezonant wrote: post #18

Please do not start publishing raw Typescript into the NPM registry thinking that all the reasons we have not done that in the past do not continue to apply. I shouldn't have to say this, but at least 27 people upvoted this article, so here we are. isolatedDeclarations is most useful for large codebases and other situations where performing a full Typescript compilation is prohibitively expensive. This is not the vas…

Id love it of npm added support for additional artifacts — separate tarballs for source, code, binaries, source maps, docs etc

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#23

Post by afavour »

rezonant wrote: post #14
pzmarzly wrote: post #10

From what I understand, the author is persuading library authors to stop compiling TS->JS, and instead ship your TS files to the users over npm. I like the idea of it, but will it actually work in practice? What if some dependency only compiles with some version of tsc? What if it needs different tsconfig-s?

> but will it actually work in practice? No. It seems like they are assuming the user is using JSR, which handles generation of JS and d.ts for you. But then none of this would even be a problem. The NPM registry doesn't do any of that. You could absolutely publish only .ts files to NPM and then use a post install script to generate JS and d.ts files, but that is a pretty terrible idea. Even if the process is super f…

You can specify different exports based on environment in the package.json so you could ship TS files… alongside JS files, so it feels a little redundant.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#24

Post by viraptor »

maxloh wrote: post #5
viraptor wrote: post #2

I feel like the point is skipped in the post: if you ship TS sources, it means you need the TS compiler on the installed side, right? And specifically the right TS version for each installed package... which in some cases may mean conflicting requirements? (If you own code is in JS, that is)

The TypeScript compiler is, in most or even all cases, backward compatible. You just need to have the latest version installed.

They may not be frequent, but they do happen https://www.typescriptlang.org/docs/handbook/release-notes/t...

And given enough public modules, we will find some conflicts in the dependency graph. YOLO just use the latest version is rarely a full solution.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#25

Post by viraptor »

rezonant wrote: post #18

Please do not start publishing raw Typescript into the NPM registry thinking that all the reasons we have not done that in the past do not continue to apply. I shouldn't have to say this, but at least 27 people upvoted this article, so here we are. isolatedDeclarations is most useful for large codebases and other situations where performing a full Typescript compilation is prohibitively expensive. This is not the vas…

> that all the reasons we have not done that in the past do not continue to apply.

Your plea would be better if you mentioned what the actual reasons are.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#26

Post by rezonant »

afavour wrote: post #23
rezonant wrote: post #14

Earlier quoted context omitted.

> but will it actually work in practice? No. It seems like they are assuming the user is using JSR, which handles generation of JS and d.ts for you. But then none of this would even be a problem. The NPM registry doesn't do any of that. You could absolutely publish only .ts files to NPM and then use a post install script to generate JS and d.ts files, but that is a pretty terrible idea. Even if the process is super f…

You can specify different exports based on environment in the package.json so you could ship TS files… alongside JS files, so it feels a little redundant.

Yes, I recommend shipping TS source alongside compiled JS+d.ts even if you don't support a TS native environment, because you then have the potential of a source mapped debugging experience within that library (though currently doing that is a bit painful in some debuggers).

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#27

Post by rezonant »

viraptor wrote: post #25
rezonant wrote: post #18

Please do not start publishing raw Typescript into the NPM registry thinking that all the reasons we have not done that in the past do not continue to apply. I shouldn't have to say this, but at least 27 people upvoted this article, so here we are. isolatedDeclarations is most useful for large codebases and other situations where performing a full Typescript compilation is prohibitively expensive. This is not the vas…

> that all the reasons we have not done that in the past do not continue to apply. Your plea would be better if you mentioned what the actual reasons are.

Sure-- the first issue is that NPM is a JavaScript registry, and it's bad form to restrict usage of your library to Typescript projects, or require non TS users to go through hoops to use your code. Additionally, if your own project executes as JavaScript (the vast majority of cases other than sort of Deno), your project will need to do special work to have JS files produced for the TS only library-- by default this won't happen so imports to the library will fail at runtime. When you do add node_modules/some-package to your TS project, this will change the structure of the files emitted into your output directory (assuming you use one, which is highly recommended), creating weird pathing like dist/src/main.js. Also the module would end up in dist/node_modules/some-package, which would be fine as long as the package isn't using non-code files within its module, which it likely is. And of course, you'd be missing all export information within that folder, which is likely to break imports, so you'll need to copy the package.json....

This is all a massive breach of encapsulation.

Is it possible to consume a TS only library distributed via NPM in a Node.js Typescript project? Yes, certainly. Is it ergonomic for consumers? No, certainly not.

Overall, it will be a bad experience for a lot of environments where JS files are expected to be present but aren't. Deno is probably the only environment that can consume NPM packages where it could conceivably work.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#28

Post by rezonant »

austin-cheney wrote: post #21
rezonant wrote: post #17

Earlier quoted context omitted.

This confuses me. You either write the d.ts manually before build, which only makes sense if you wrote the original code in JavaScript (not Typescript) or you write the source in Typescript and enable the declaration option in your tsconfig and the d.ts pops out in seconds along with your final JS output. Unless you are using transpileOnly, generating declarations will not make a few second build become a few hours--…

I write TypeScript projects in TypeScript from the start. If I have an existing JS project that needs to port to TypeScript then I will rewrite it entirely in TypeScript. Yes, that takes some small amount of time, but it’s never a complete rewrite. It’s mostly just minor syntax updates as the actual runtime should remain the same as validated by test automation. I type everything I declare whether a primitive or not.…

[dead]

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#29

Post by rezonant »

seniorsassycat wrote: post #22
rezonant wrote: post #18

Please do not start publishing raw Typescript into the NPM registry thinking that all the reasons we have not done that in the past do not continue to apply. I shouldn't have to say this, but at least 27 people upvoted this article, so here we are. isolatedDeclarations is most useful for large codebases and other situations where performing a full Typescript compilation is prohibitively expensive. This is not the vas…

Id love it of npm added support for additional artifacts — separate tarballs for source, code, binaries, source maps, docs etc

Fair, but if you don't fall into the pit of despair by consuming micro libraries (ie "is-true" or "leftpad"), the overhead of having source and source maps present on a developer environment or even a server deployment is not terrible. If you are bundling for web delivery, those files will be omitted automatically by nature of the bundling process.

While it would be nice to have native support for package components, personally I think the best path is to ship all of it (save perhaps documentation, where there's currently no ergonomic way for a consumer to make use of it) in the main package.

The above is assuming "docs" mean some kind of external documentation, you absolutely should not strip out your docblocks when you package your code. Ditto for minification: Just don't. If the end user needs to optimize for size, they will be minifying anyway, all packaging minification does is create painful debugging and code reading experiences for consumers.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#30

Post by rezonant »

crooked-v wrote: post #19
streptomycin wrote: post #9

Earlier quoted context omitted.

You wouldn't, you would use JSR.

I despise this recurring trend in the JS-adjacent world of "cutting edge" people making their published packages intentionally incompatible with what everyone else is doing.

Well, if they want no one to use their libraries, then fine. You would think that as a person publishing library code to a public registry, you would be incentivized to ensure your code is broadly usable. At least in general.

I know this is in the context of JSR where this isn't an issue, but I suppose some people just want to just use a registry as a personal code repository. Id just hope they don't pollute the top level namespace in that case.

Who am I kidding, sadly for NPM that ship sailed years ago :*-(

Post reply on HN