See also https://publint.dev/
Also attw [1]. I run both tools in CI to ensure package correctness.
[1] https://github.com/arethetypeswrong/arethetypeswrong.github....
TypeScript NPM Packages Done Right
71–80 of 81 posts
Re: TypeScript NPM Packages Done Right
#72Earlier quoted context omitted.
Esbuild works fine and is also much faster than TSC. Also TS enums are flawed: https://blog.logrocket.com/why-typescript-enums-suck/
> enums flawed I like Typescript enums generally, my only complaint is that they are kept in the final build as big objects, especially in the scenario where you don't enumerate them. I use a replace function with terser to replace them with inlined constants to make my fine build smaller.
That's what `const enum` is for!
Re: TypeScript NPM Packages Done Right
#73While the article is technically correct it avoids the most common issue with 'pure' typescript libraries in that you still need a bundler if you have multiple .ts files. Once you enter that territory you realize how much more complex everything becomes.
You don't need a bundler with multiple .ts files any more than with multiple .js file - which is that you don't "need" one at all. Libraries especially don't and should be published to npm unbundled. Bundling is purely an application concern.
So consumers are forced to use a bundler/ts just because some random dependency decided they're too lazy to deal with a bundler?
> Bundling is purely an application concern
by this logic all compiled languages' repos should just be source, no precompiled binaries.
Re: TypeScript NPM Packages Done Right
#74Earlier quoted context omitted.
You don't need a bundler with multiple .ts files any more than with multiple .js file - which is that you don't "need" one at all. Libraries especially don't and should be published to npm unbundled. Bundling is purely an application concern.
So consumers are forced to use a bundler/ts just because some random dependency decided they're too lazy to deal with a bundler? > Bundling is purely an application concern by this logic all compiled languages' repos should just be source, no precompiled binaries.
yes. Always include source and let the user/client decide. Include a bundled version is OK, but it should be only there for convenience.
Re: TypeScript NPM Packages Done Right
#75Earlier quoted context omitted.
So consumers are forced to use a bundler/ts just because some random dependency decided they're too lazy to deal with a bundler? > Bundling is purely an application concern by this logic all compiled languages' repos should just be source, no precompiled binaries.
yes. Always include source and let the user/client decide. Include a bundled version is OK, but it should be only there for convenience.
so explain to me again why I have to change my entire toolchain for simply consuming a library? What if I consume a wasm library written in Rust, suddenly I have to add rust into my build script? What is the point of bytecode if people are going to repeat the same build over and over again anyway?
Re: TypeScript NPM Packages Done Right
#76Earlier quoted context omitted.
Link to full cheatsheet: https://www.totaltypescript.com/tsconfig-cheat-sheet
This cheatsheet would have you publish dist/*.{js,d.ts}. Presumably you would use "files":["dist"] in package.json to exclude sources from being published. The OP recommends to additionally package src/*.ts along with sourceMaps and declarationMaps. What's actually the best practice here?
I poke around in node_modules with some regularity (often in combination with the debugger) and it’s always nice to find actual source files, not just source maps.
Re: TypeScript NPM Packages Done Right
#77Earlier quoted context omitted.
Note that jest before v27, and some other runtimes, don't support export maps.
Jest and every other major runtime/bundler has supported exports for a couple years. I.e. if you're releasing a package today, you probably don't have to worry about support.
A package I help maintain was released about a month ago, and we've had bug reports related to this: https://github.com/openai/openai-node/issues/304#issuecommen...
We simply chose to mark Jest 27 as unsupported in this case, but it did cost some debugging time.
Re: TypeScript NPM Packages Done Right
#78Earlier quoted context omitted.
yes. Always include source and let the user/client decide. Include a bundled version is OK, but it should be only there for convenience.
so explain to me again why I have to change my entire toolchain for simply consuming a library? What if I consume a wasm library written in Rust, suddenly I have to add rust into my build script? What is the point of bytecode if people are going to repeat the same build over and over again anyway?
it's unfortunate that javascript (and typescript) is not bytecode.
Re: TypeScript NPM Packages Done Right
#79Earlier quoted context omitted.
so explain to me again why I have to change my entire toolchain for simply consuming a library? What if I consume a wasm library written in Rust, suddenly I have to add rust into my build script? What is the point of bytecode if people are going to repeat the same build over and over again anyway?
it's unfortunate that javascript (and typescript) is not bytecode.
It's the same in that js is the standard runtime, and typescript is something that compiles to it, that's NOT used in all codebases
Re: TypeScript NPM Packages Done Right
#80"module": "commonjs", Nope.
Anecdotally, ESM has been an absolute nightmare. Packages that aren’t compatible without code changes, having to add extensions to every single import unless we specify a flag (that is now deprecated), challenges with import maps and module resolution, the list goes on. So we just use CommonJS with project references and call it a day. Everything works and we don’t need to change any of our code. The way ESM was intr…
I've been doing node for 10+ years and it was the python 2vs3 moment for me
I started using Rust for quick and dirty programs, web services, small frontend apps - and I noticed: - slower to prototype simple things compared to node CJS - equal or faster when compared to TypeScript - faster to get complex things right