17 ms·

A Node, TypeScript, TS-Node and ESM experience that works

198 points by khalidx 3y ago

austin-cheney 3y ago
The experience of using Node.JS with TypeScript, ts-node, and ESM is horrible. I completely disagree. This has always felt immediately straight forward to me. I suspect this struggle, a struggle I completely don’t understand, explains the complexity of hiring for these kinds of jobs. I really felt that to get hired for these jobs you had to be willing to play stupid games and abandon all reason to worship at the pulpit of giant frameworks and third party solutions. Fortunately, I have moved on to something else.
- Yiin 3y ago
  I'd love to see you live stream a process of creating a project consisting of several different apps using same ts config and shared libs folder from scratch using these tools.
  - austin-cheney 3y ago
    In my personal projects I use ”type”: “module” in the package.json. In my tsconfig.json I use { "compilerOptions": { "alwaysStrict": true, "module": "ES2020", "moduleResolution": "node", "outDir": "./js/lib", "noEmit": true, "noImplicitAny": true, "pretty": false, "strictFunctionTypes": true, "target": "ES2020", "types": ["node"], "typeRoots": ["./node_modules/@types"] }, "exclude": [ "js", "lib/terminal/test/storageTest/temp", "**/node_modules", "**/.*/" ], "include": [ "**/*.ts" ] } Internally in your apps never never use relative file system paths.
    - khalidx 3y ago
      Is alwaysStrict the same as strict? I think this skips a lot of the strict options that are usually the case for using TypeScript in the first place.
      - austin-cheney 3y ago
        According to the TypeScript documentation for tsconfig.json the alwaysStrict option forces the compiled out to strict mode such that the JIT interpreter parses it as such. This happens anyways when using ES6 modules, but it also ensures the TypeScript compiler parses each file in strict mode regardless of having the "use strict" pragma at the top. https://www.typescriptlang.org/tsconfig#alwaysStrict https://www.typescriptlang.org/tsconfig#alwaysStrict
        khalidx 3y ago
        I just dug a bit deeper as I couldn't remember the differences. They're not referring to the same things. "alwaysStrict", which adds "use strict", is different than TypeScript "strict" mode, which constrains the language. Setting "strict" to "true" enables "alwaysStrict", but not the other way around. I'd remove "alwaysStrict" and go with "strict" as it covers more things.
quackware 3y ago
- Why include files, exports, and types in your package.json when you are just using ts-node to transpile on the fly? - ts-node is much slower than something like esbuild/tsx right? As long as you rely on your ide type checking or run type checking before deploying your app.
- khalidx 3y ago
  The "exports" and other sections are recommended things you'll need in your `package.json` file to support ESM. Sensible defaults. Also just points to an index.ts file (that you'll likely have in your project if you are developing a package). Also, this project can be compiled with `tsc` or a bundler, of course. In terms of speed, this should consistently start up an app or CLI in <3 seconds (depending on size of course).
rickcarlino 3y ago
I’ve found TSX to be a better alternative to ts-node. It seems to have more sensible defaults in 2023. https://github.com/privatenumber/tsx https://github.com/privatenumber/tsx
- lloydatkinson 3y ago
  I was about to say exactly this. If you’re writing Node scripts there’s no reason to use ts-node as tsx, by default, does the correct thing and works correctly with ES modules. Of course, Deno offers a better experience for scripts or programs.
  - khalidx 3y ago
    I tried `tsx` but it didn't work for some reason (can't remember why right now). Also, if you've been using `ts-node` and feel comfortable with it, this setup should work for you instead of switching your toolchain.
    - privatenumber 3y ago
      tsx v4 was released a couple weeks ago which addressed many incompatibility issues. Hope you have a chance to give it another shot :)
      - khalidx 3y ago
        I definitely will!
- vmfunction 3y ago
  or esno, which is tsx with esbuild.
  - lhnz 3y ago
    I'm using `esyes` [0] by Yehuda Katz and the logic is simple and it works very well. [0] https://github.com/starbeamjs/esyes https://github.com/starbeamjs/esyes
toastercat 3y ago
Also see TSM: https://github.com/lukeed/tsm https://github.com/lukeed/tsm
WolfOliver 3y ago
Agree it is a little tricky to get startet. But once configured, it helps a lot
jna_sh 3y ago
This is not a guide, it's three config files
- khalidx 3y ago
  You're right, but what guide is easier than "Just add the following files and run npm run dev. You'll be good to go!".
  - bilekas 3y ago
    I'm personally against that belief as it doesn't really teach anything. Just adds a list of bootstrapping that you don't understand.
    - jenscow 3y ago
      There's only so much spoon-feeding that can be done. We already have so much information at our fingertips. If people just want to copy+paste it then mark a jira issue as complete, that's up to them. However, for those of us who want to understand - sometimes it's better to see a working example and pick at it.
    - codingdave 3y ago
      I find that almost all devs have a layer at which they don't understand what is going on. Everything we do is built on the shoulders of giants, as evidenced by how little we think about the 0s and 1s that are the actual end result of our work. So I don't see a problem with any dev having a line of non-understanding as they work. Some peoples lines are lower than others, but we all work that way. So it is all good.
      - bilekas 3y ago
        Absolutely, but don't call it a guide. When it's not.
      - chii 3y ago
        > how little we think about the 0s and 1s that are the actual end result of our work. but that doesn't mean you don't understand it. You can get away with not thinking about it - for example, the error correction algorithms and protocols in tcp, or memory access - and that's because the designers of those layers have thought hard and long about how to keep it from leaking. For js ecosystem, the designers (?) didn't think much at all. It is hobbled together rather haphazardly over time. Leading to the mess today.
pyrolistical 3y ago
this setup doesn’t work with node test runner. I had to tsc then node --test the built files. tsx also is missing the test runner https://github.com/privatenumber/tsx/issues/257 https://github.com/privatenumber/tsx/issues/257
- e1g 3y ago
  With tsx instead of ts-node, it works just fine - node --import=tsx --test __tests__/\*/\*.test.ts
  - pyrolistical 3y ago
    Including failed tests?
ivanjermakov 3y ago
And if you publush it, imports are going to be from 'pkg/dist/foo'..
bovermyer 3y ago
In order to be a guide, I feel like it would need to explain _why_ each thing is there and what it does.
EdSharkey 3y ago
A gist, the digital equivalent of scribblings on a stained cocktail napkin, lays bare the great mystery. The great dragon is slain! His precious treasure is of no value whatsoever. Fellow scrounging raccoons, raise your chipped mugs and cracked cups! Let us toast to our fortune, we truly are the blessed ones.
w3news 3y ago
Why not using Node how it is designed, than ESM works great. For type checking on development, you can do it with ESLint and JSDoc in Typescript modus. You have the same type checking like you have in ts files. You can even import types from typescript files, like .d.ts Best of both worlds, no transformation of the code, and on development you have some help from Typescript.
vasergen 3y ago
> The experience of using Node.JS with TypeScript, ts-node, and ESM is horrible. So true, I really wandering if there was a better alternative, they essentially broke a lot of packages and I don't know how many dev hours will be put now to fix all of this, because so many tools are broken now. Additionally to that, they did some other not backwards compatible changes, like removing __direname in ESM, which is IMHO not the best decisions, why not for example just keep it as it is, but deprecate it and have a warning message.
- khalidx 3y ago
  I agree that the migration experience has been subpar! I dropped ESM migration of my packages 2-3 times before finally picking it up again and wrapping it up in a simple guide. Hopefully with the config I shared you’ll find that you can use all those out-of-reach ESM packages now! Also, I provided examples for getting __dirname and __filename -like behavior.
- azangru 3y ago
  > a better alternative Deno?
jampekka 3y ago
https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d...
- khalidx 3y ago
  Strong agree. This has caused a major rift in the Node ecosystem (and for its packages). All we can do is adapt and keep building. Using Node v20 (LTS) currently with the config linked in the parent post.
demurgos 3y ago
I always found it easier to avoid `ts-node` as it introduced a bunch of small compat issues. Since TS 4.5 and their support for `.mts`, I finally settled on just chaining `tsc --build && node ./build/main.mjs`.
- khalidx 3y ago
  I generally agree with your statement, but have found ts-node incredibly valuable especially when developing servers or CLIs where I want to start/restart the process many times without a build step every time.
  - SahAssar 3y ago
    Node has a built in watch mode and so does tsc. So if you start both you should get what you want.
- azangru 3y ago
  And for development?
  - demurgos 3y ago
    With TS, I get type checking in the IDE; I don't need to rebuild every few seconds. When I actually need to build and test, it's very fast (<2 seconds). I use Yarn workspaces/subprojects and TypeScript references with incremental builds so it's not really an issue. Here is the `package.json` [0] for a serialization lib I did, you can check the `scripts` section: it's very minimal and I'm quite happy with it. I'm an old Gulp maintainer, so for a long time I had heavy Gulp config with a lot of processing. Over the years I could get rid of it. ESM was the last thing holding me back; and now I'm so happy that I can just use a few simple commands. [0]: https://github.com/demurgos/kryo/blob/master/packages/kryo/package.json https://github.com/demurgos/kryo/blob/master/packages/kryo/p...
- beepbooptheory 3y ago
  or: `tsc --build --watch` and then just have another terminal to run.
dalore 3y ago
[flagged]
koolba 3y ago
Many people in this thread are rightly complaining that this does not answer the "why does this work". Having a working example is a good start for that though as at least you have a known target and as you change things (and break things), you can see what those options did. One problem with this guide that makes that trickier is that the tsconfig.json itself imports https://github.com/sindresorhus/tsconfig/blob/5c87dc118e057dc16fe1e62c990645000dbfaac7/tsconfig.json https://github.com/sindresorhus/tsconfig/blob/5c87dc118e057d... and overrides a bunch of values. So if you really want to understand what it's doing, you need to get rid of that dependency and inline / merge that config file. That would also add stability to your project as it's one less upstream dependency out of your control (and a big one at that as it controls how you entire project is built!). For example the imported tsconfig.json changes these: "compilerOptions": { // ... "module": "node16", "moduleResolution": "node16", "moduleDetection": "force", // ... "allowSyntheticDefaultImports": true, // To provide backwards compatibility, Node.js allows you to import most CommonJS packages with a default import. This flag tells TypeScript that it's okay to use import on CommonJS modules. "jsx": "react", // ... } But you wouldn't notice that if you just look at the gist. It'd just be a magic that you can write React code in a .tsx file. Clearly that has to be enabled somewhere.
- btown 3y ago
  https://documentation.divio.com/ https://documentation.divio.com/ is a good overview of the "four types of documentation" paradigm: tutorials, how-to guides, explanations, and reference have to all exist. One of my major gripes with the JS/TS ecosystem is that "explanations" are sorely lacking. See https://www.typescriptlang.org/tsconfig https://www.typescriptlang.org/tsconfig for the relevant documentation for tsconfig files. Tutorials are on the page, how-to guides abound on the wider internet (like the OP), and the linked TSConfig Reference and JSON Schema (used in code completion in IDEs) are together absolutely massive. But an explanation is missing! There is no official documentation about how different options interact to say: as I'm walking a file tree as the Typescript compiler, this is how I will interpret a certain file I encounter, what will be outputted, and how that will be interpreted by bundlers and browsers, especially in an ESM world. https://medium.com/extra-credit-by-guild/tsconfig-json-demystified-d8f333e578c1 https://medium.com/extra-credit-by-guild/tsconfig-json-demys... is in the right direction, but outdated as ESM has become much more popular in the past 3 years, and still organized by option (so it's already somewhat in the "reference" world). IMO even independent of documentation, the industry's move to ESM is problematic: https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d... describes many of the issues. But they're certainly exacerbated by good explanation-style documentation that helps people understand how ESM works under the hood!
paradite 3y ago
I am pretty sure "type": "module" doesn't work with React Native/Expo and jest (in 2022 last time I tried). If you Google the error you will get stackoverflow posts with hundreds of upvotes. And that's the main problem with using ESM - 3rd party library support. It is trivial to do hello world in ESM with Node.js, but try that with 10 dependencies and quickly you will be hit errors.
Rapzid 3y ago
Module resolution "bundler". ts-node --esm --swc Haven't really had any issues with this in a long time.
tuyiown 3y ago
Add eslint and jest to pull your hairs of you head. I managed to get it right last week, but I'm pretty confident that next upgrade I'll have to revise most of it.
- rickstanley 3y ago
  Have you considered using Vitest? Its performance has had a significant impact on my workflow and the workflow of my colleagues. It supports ESModules by default.
  - tuyiown 3y ago
    Ah! thanks a lot, I'll give it a good look next round, but I won't have much difficulty moving from jest, because its old roots triggers too much unexpected and hard to anticipate constraints.
drtgh 3y ago
Node.js, TypeScript (compiled script...), ESM modules, versions, and the dependencies tree hell... You guys are adopting the masochism, the problem is that you are dragging the rest of us into that hell.
- bovermyer 3y ago
  I'm going through a special version of this hell right now at work. I'm updating old Lambdas that are on the node.js 12 runtime. Some of them have internal dependencies that just _no longer exist_, or aren't compatible with Node past 14. Meanwhile, all I had to do to update old Python Lambdas was just update the runtime itself.
  - postalrat 3y ago
    https://www.google.com/search?q=python+version+hell https://www.google.com/search?q=python+version+hell
    - bovermyer 3y ago
      Note that in my original comment, I didn't say Python doesn't have version problems. I said my (specifically my) Lambda version migration problems were much worse with Node.js than Python. Also, I'm vaguely offended that you used a "let me Google that for you" reply as your sole comment. Did you really have nothing more intelligent to add than low-effort snark? Go back to Reddit.
      - postalrat 3y ago
        A lot of people have versioning problems in all languages. You said "Meanwhile, all I had to do to update old Python Lambdas was just update the runtime itself. ". You know that isn't always true in Python that you just update the runtime and nothing goes wrong.
        bovermyer 3y ago
        True, but Node.js is far worse when it comes to dependencies and _their_ dependencies.
dangoodmanUT 3y ago
This is why I use bun now! It just works, NodeJS is such a shit show right now, feels like the python 2->3 move.
- davidy123 3y ago
  I tried to use Bun but it doesn't support some low level Node APIs properly, in my case for Playwright. Keeping an eye on it though, what I saw seeemed promising.
  - sroussey 3y ago
    Make an issue. I did so for various compat issues and they are fixed now.
    - davidy123 3y ago
      There are already long running issues on this topic. https://github.com/oven-sh/bun/issues/2492 https://github.com/oven-sh/bun/issues/2492
- jzig 3y ago
  I've been curious about using Bun. Could you point to an example of something like Node backend code that's written in TS using Bun?
monooso 3y ago
I see (and have participated in) a lot of this "just copy this thing, trust me it works" type of content related to Node and TypeScript. It makes me wonder why Deno [1] still seems to be such a niche choice. Most of these headaches just go away. Does anyone here prefer Deno for new projects? And if not, why? [1] And Bun, although that's much newer.
- mark_and_sweep 3y ago
  Being using Deno for new projects for years now. Not looking back.
  - robbywashere_ 3y ago
    What are the advantages of deno over node?
    - flohofwoe 3y ago
      Not the parent, but one very nice aspect is that an entire working Deno installation is just one file: the actual deno executable. ...when installing via homebrew on Mac you get 3 more files which look like shell-completion definitions: bin/deno etc/bash_completion.d/deno share/fish/vendor_completions.d/deno share/zsh/site-functions/_deno
      - e1g 3y ago
        Both Node.js and Bun are also single executables. Node.js doesn't (yet) transpile TS for you, and that's a single dependency away.
        flohofwoe 3y ago
        Yeah I was confused that the Node installation directory was showing me 18k files in several thousand directories, but these seem to be global npm installs which npm seems to put into the node installation directory (which tbh is weird, I would expect those somewhere in my user directory).
davidy123 3y ago
I'm going to keep hitting reload on this page until someone solves some of the worst problems of my work life right now; getting a npm monorepo with typescript, eslint and jest working smoothly. Thank you to whoever(s) that is. I'm trying to make a public project, but building/developing with it is successive layers of sometimes-works voodoo that have nothing to do with the project goals. Somewhat compounded when members of nx (nee lerna) popped in to try to help, adding another layer of sometimes-works. As it is, DX depends on a fast computer to basically rebuild the whole thing each time, or running build & test in a dozen workspaces, because I haven't found any other reliable "workflow."
- searchableguy 3y ago
  We gave up and switched to vitest.
  - flohofwoe 3y ago
    +1 for vitest :D I was amazed that it "just worked" after struggling for hours getting jest to work because of silly file extension problems (really... what's up with that... wouldn't that be easy to fix if the Node.js and Typescript teams would talk for 5 minutes and agree on one approach?)
  - davidy123 3y ago
    I don't use Vite though. Aside from typescript, I'm trying to be as vanilla/unopinionated as possible, using Web Components for example. And there are hundreds of Jest tests I don't want to port.
    - flohofwoe 3y ago
      You can use vitest like a standalone testing tool, it will install vite as dev-dependency but you don't need to build your whole project around vite. In my case it was literally a drop-in-replacement for jest, done in two minutes and without a config file. A simple config file only was required a bit later when I added test- and coverage-reporting as junit.xml and cobertura format for Gitlab CI. Didn't even have to change a single line of testing code (I didn't use Jest's mocking magic in that project though).
resters 3y ago
I thought there were "presets" that NPM and Yarn knew about to do this kind of thing...
sirius87 3y ago
The current ESM experience makes it seem like decision-makers in the node.js project were wilfully oblivious to how large the TypeScript community was and how it was being used in node modules and projects. It really does feel like the maintainers focus was on JS and harmony with TypeScript's evolution was low on the priority list. Meanwhile anyone using an intersection of TypeScript with jest and any of sindresorhus' libraries when he flipped to ESM for his bajillion libraries immediately felt the downside and moved hard away from ESM. Imagine the mind-boggling hours lost just to get these export/import formats to glue.
- madeofpalk 3y ago
  I really enjoy frontend/node/typescript development. I roll my eyes whenever the HN-types complain about CSS or frontend development being a hellhole. Mostly the comments I see seem ignorant or impatient ("Why doesn't this thing work without be bothering to learn it?") However, the intersection of typescript, nodejs, and ES modules is consistently the most frustrating experience I ever have. Trying to figure out which magic incantation of tsconfig/esbuild/tsc/node options will let me just write code and run it is a fools errand. You might figure something out, and then you try to use Jest and then you descend into madness again. The biggest tip I can give people is to ditch ts-node and just use (the awkwardly named) tsx https://github.com/privatenumber/tsx https://github.com/privatenumber/tsx, which pretty much just "mostly works" for running Typescript during dev for node. The problem mostly seems to stem for all the stakeholders being pretty dogmatic to whatever their goals are, rather than the pragmatic option of just meeting people where they are. I really wish the Node, Typescript, Deno/Bun, and maybe some bundler people would come together and figure out how to make this easier for people.
  - sirius87 3y ago
    Totally agree. It's doubly frustrating because a standard for authoring modules across browser and server platforms such as ESM is a good thing. But it's a bit arrogant to expect module authors across TS and JS ecosystems to ship overnight. Beginners may just turn to Deno or Bun simply because hundreds of coding tutorials and snippets no longer work. Or, when you finally get a TS config that works but then you import @aws-sdk/* or prisma seeds and then you really rip your hair out.
bearjaws 3y ago
Main reason I even tried bun out. Honestly 'just works', I've only had one issue so far and it was with a unpopular compiled module.
- sroussey 3y ago
  I love it. Had some issues with terminal stuff, now fixed. Just works, indeed. But I have a difficult time trying to get a project make to node/ts.
- mst 3y ago
  I'm really enjoying bun for my own stuff but tsx looks more promising for work projects.
solatic 3y ago
Having tried to wrangle all of this both professionally and for a side project, the link is an over-simplification. No, it won't "just work". Part of the problem is the fact that web browsers, Node.js, and other JS runtimes have slightly different needs and expectations. Part of the problem arises when you're trying to mix and match web code, Node.js code, and other JS runtime code in the same monorepo. There's no single magic-bullet configuration.
_nalply 3y ago
One problem I encountered with ESM TypeScript development on the browser without bundling: many Node packages aren't set up for that. You might ask why without bundling? Sometimes you just want to start something simple on the browser and compile to JavaScript on the fly. I tried the dev server from Modern Web [0], and I liked it. I program in TypeScript and the browser reloads whenever I save a file. Of course I could set up a bundler and for a small program waiting times are negligible. But I hate bundlers. I know it's irrational, but nowadays I program for fun so I think I should have the choice to reject bundlers. This fails for many Node dependencies. There is a conflict between CommonJS and ESM. I am not 100% sure that what I want to achieve is impossible without forking dependencies and making a small change. I even found a way to have a CommonJs and ESM polyglot, but this hack is extremely ugly. I named the hack modglot [1]. I don't think this is a good idea and I don't understand enough to propose something. I am somewhat dejected about the current state of TypeScript development for the browser and paused development. Now I am programming in Rust again just for fun, but if I return to TypeScript, probably I will try out Deno. [0]: https://modern-web.dev/guides/dev-server/getting-started/ https://modern-web.dev/guides/dev-server/getting-started/ [1]: https://github.com/nalply/modglot https://github.com/nalply/modglot
cantSpellSober 3y ago
Does Node.js plan to transpile TS out-of-the-box soon? (Picking up a legacy project, can't swap out for Deno or another runtime just yet)
- khalidx 3y ago
  This would be a nice direction for the Node community. I wish for this. Especially since so many other platforms are supporting it out of the box.
dackerlunghack 3y ago
[dead]
tommy_guo 3y ago
Sharing https://github.com/tommyguo/node_monorepo https://github.com/tommyguo/node_monorepo if this helps folks. It's a Typescript monorepo template with everything you need included. I'm currently using this setup to run multiple services on AWS.
preommr 3y ago
> Just add the following files and run npm run dev. You'll be good to go! This attitude just doesn't work for js ecosystem. I have some shell scripts, vim config files, etc. that I don't remember what they do, but I just copy over and they work. Coding projects are different; they break all the time. Especially with how fast the js/ts ecosystem works. One day, a crucial library just decides that it's changed something that doesn't work with the build process because there's so many variations of them that they can't possibly all be tested against.
bhouston 3y ago
I did some experiments myself and settled on this template repository: https://github.com/bhouston/template-typescript-monorepo https://github.com/bhouston/template-typescript-monorepo This has a lot of features that work well together: - TypeScript - ESM - Node.JS Server + React + Cli - Monorepository - Fast Incremental Updates Feedback welcome. I use this for about a dozen different projects now.
conaclos 3y ago
Some comments and suggestions: - `importsNotUsedAsValues` is deprecated [0] since TypeScript 5.2, in favor of `verbatimModuleSyntax` [1]. - I could set `module` to `Node16`. This automatically set `esModuleInterop` to true. - Also, to catch more issues, set `allowUnreachableCode` to false and set `strict`, `noImplicitReturns`, `noImplicitOverride`, `noFallthroughCasesInSwitch`, `exactOptionalPropertyTypes` to true. - Set `types` to the empty array `[]` to avoid loading unwanted types. - Enable `skipLibCheck` to avoid checking imported module types. - Not sure that `declarationMap` is still useful nowadays. TypeScript is now able to match directly against source files. - Enable `composite` that in turns enables `incremental` and `declaration` (declaration file emit). `composite` enables project references which is useful in a monorepo setting or to separate source and test files into two projects. See [2] - Enable `checkJs` to type-check JavaScript files To summarize: { "$schema": "https://json.schemastore.org/tsconfig", "compilerOptions": { "lib": ["ES2022"], "module": "Node16", "target": "ES2022", "outDir": "./dist", "composite": true, "sourceMap": true, "types": [], "isolatedModules": true, "resolveJsonModule": true, "skipLibCheck": true, "verbatimModuleSyntax": true, "allowUnreachableCode": false, "checkJs": true, "exactOptionalPropertyTypes": true, "noFallthroughCasesInSwitch": true, "noImplicitOverride": true, "noImplicitReturns": true, "strict": true } "include": ["./src/**/*.ts"], "exclude": ["./src/specific-file.ts"] } [0] https://www.typescriptlang.org/tsconfig#importsNotUsedAsValues https://www.typescriptlang.org/tsconfig#importsNotUsedAsValu... [1] https://www.typescriptlang.org/tsconfig#verbatimModuleSyntax https://www.typescriptlang.org/tsconfig#verbatimModuleSyntax [2] https://www.typescriptlang.org/docs/handbook/project-references.html https://www.typescriptlang.org/docs/handbook/project-referen...
rglover 3y ago
Hear me out: if you need to do this just to use a tool effectively, maybe it's a bad tool.
- wruza 3y ago
  We're open to suggestions!
  - rglover 3y ago
    In this specific context: just use plain JavaScript with default args and your own, inline type checker functions. No need for stuff like this and you can customize type checks to your heart's content.
wruza 3y ago
Ah, I upgraded just yet, realized node 20 broke the way ts-node-esm loader works. Had to downgrade to 18, because there's no functionality I really need from 20. Also Vite complained when I tried node 19, because it requires <=18 && >=20 for some reason (probably good one). I'm maintaining a few pristine example projects to keep track of these ways and test them periodically. This iteration probably had the shortest lifetime. I didn't manage to develop even a single toy project before something got obsoleted again. Love this community. Looking forward to solve a handful of brand new issues with tsx. I wish there was some IDEish starter pack which you could install and start writing code anytime, without investigating issues with running a damn interpreter.
- jb_hs 3y ago
  My guess is node 19 isn't an LTS version and it's hard enough to maintain just the LTS versions. Probably a requirement that will save a lot of pain...
c-hendricks 3y ago
I've been trying to upgrade a couple of libraries we use internally at work to output CJS + ESM, from a typescript project, and have the output be 1-to-1 files (so, no bundling / rollup / whatever you want to call it). What a frustrating experience it has been. Using unbuild "works", but - For the life of me, I can't get unbuild to generate `.d.mts` files when my source files don't have `.mts` extensions. Luckily, when the library is used in a downstream project and a `.mjs` file is imported, TypeScript properly loads the `.d.ts` file anyways - When it comes to a downstream project, TypeScript doesn't seem to work with export maps. People say it does, but maybe because I don't have `.d.mts` files TypeScript is saying it can't find type information? It _does_ work with simple export maps, but if I say `'./': './dist/esm/'` so the downstream project doesn't have to manually import from `dist/esm` I see the issue - Using the "esm" module / moduleResolutions + converting my files to `.mts` + changing imports in the source to import the non-existant `.mjs` files results in a CJS bundle that tries to require a `.mjs` file, which unbuild has built with a `.js` extension, so it throws an error because it can't find the file. - For some reason unbuild mucks with the hashbang line in my _CJS_ `bin` script, the ESM one it doesn't touch Ugh.
- moltar 3y ago
  Try tsup it does just work unless your package is doing something funny. Then do a check with attw cli tool and it’ll report your compat mistakes with links to explainer docs.
  - c-hendricks 3y ago
    That's what I tried using before and I had even less luck / had to do more fandangling, but thanks for the suggestion. Like I said, these are libraries whose "build" before was just `tsc`, there's nothing funny going on.
    - moltar 3y ago
      Share a repro I’ll sort you out. Gotten good at this bullshit :D
dimgl 3y ago
+1 to what one of the commenters is saying. You can skip all of this and just use `tsx`. I currently sponsor that project. That's how impactful it was on all of my development. I will say that it's kind of sad that Node.js has devolved into this.
apitman 3y ago
Typescript is a huge improvement over JS, but I never use it. My rule of thumb is that if TS provides a tangible benefit, I have too much complexity on the frontend.
kshahkshah 3y ago
Now add eslint and prettier :)
nop_slide 3y ago
Could someone succinctly describe the situation between node ts and esm? I’m not very familiar with the ecosystem and trying to understand what pain ports people are describing here in the comments.
awongh 3y ago
I just got started with a Next.js project coming from React with JS and…. another JS/TS rant incoming….. For an ecosystem that purports to be ready for professional use it absolutely boggles my mind that the tooling is stuck at this very amateurish level. Why isn’t there a ready preset for me to use ESM syntax with Next.js / Typescript? What’s wrong with the culture around Node/TS/JS tooling in general that it’s so consistently broken all the time? What the hell.
- eddd-ddde 3y ago
  Try QwikJS. It solves what you ask for, create a project and you are ready to go. Qwik feels so right to use, if you have 5 minutes you should read about it: https://qwik.builder.io/docs/concepts/think-qwik/ https://qwik.builder.io/docs/concepts/think-qwik/
SnoozingBoa 3y ago
Here comes a question what many of the people reading the comments are thinking: As of November 2023, what is the canonical way to set up a Node project with Typescript and hot reload? Minimal setup with least amount of configs and tooling. I am not after any other tools like Bun.
- ycombinatornews 3y ago
  Snowpack, parcel, esbuild. Minimal setup each. YMMV based on how you plan to distribute the build results (package, site or app) after.
  - vlod 3y ago
    Maybe I'm not getting it, but I just set up an express.js app this last weekend with nothing much more than tsc (typescript) and ts-node. Do you need all that other stuff for a simple node app?
    - toastercat 3y ago
      You are getting it. Use less and smaller tools if possible. And if you're on Node 18, node comes with a watch mode built in that you can leverage. You can alternatively use esbuild to handle the TypeScript compilation since it is faster than tsc for that, and just keep tsc around for the typechecker.
  - toastercat 3y ago
    Snowpack has been unmaintained for years now, and its homepage actively recommends people switch to Vite.
demondemidi 3y ago
"...for a few months." Until this github repo dries up the same way similar attempts at this have.
diamondfist25 3y ago
I really detest this JS dx. Ideally things are great — do ur frontend dev in js and backend in js. With TS added for better dx. Except 90% of the time ur fighting the configs of why its not importing/requiring U change from .js, .ts, .cjs, .mjs and nothing works

198 points by khalidx 3y ago

The experience of using Node.JS with TypeScript, ts-node, and ESM is horrible. I completely disagree. This has always felt immediately straight forward to me. I suspect this struggle, a struggle I completely don’t understand, explains the complexity of hiring for these kinds of jobs. I really felt that to get hired for these jobs you had to be willing to play stupid games and abandon all reason to worship at the pulpit of giant frameworks and third party solutions. Fortunately, I have moved on to something else.

Yiin 3y ago
I'd love to see you live stream a process of creating a project consisting of several different apps using same ts config and shared libs folder from scratch using these tools.
- austin-cheney 3y ago
  In my personal projects I use ”type”: “module” in the package.json. In my tsconfig.json I use { "compilerOptions": { "alwaysStrict": true, "module": "ES2020", "moduleResolution": "node", "outDir": "./js/lib", "noEmit": true, "noImplicitAny": true, "pretty": false, "strictFunctionTypes": true, "target": "ES2020", "types": ["node"], "typeRoots": ["./node_modules/@types"] }, "exclude": [ "js", "lib/terminal/test/storageTest/temp", "**/node_modules", "**/.*/" ], "include": [ "**/*.ts" ] } Internally in your apps never never use relative file system paths.
  - khalidx 3y ago
    Is alwaysStrict the same as strict? I think this skips a lot of the strict options that are usually the case for using TypeScript in the first place.
    - austin-cheney 3y ago
      According to the TypeScript documentation for tsconfig.json the alwaysStrict option forces the compiled out to strict mode such that the JIT interpreter parses it as such. This happens anyways when using ES6 modules, but it also ensures the TypeScript compiler parses each file in strict mode regardless of having the "use strict" pragma at the top. https://www.typescriptlang.org/tsconfig#alwaysStrict https://www.typescriptlang.org/tsconfig#alwaysStrict
      - khalidx 3y ago
        I just dug a bit deeper as I couldn't remember the differences. They're not referring to the same things. "alwaysStrict", which adds "use strict", is different than TypeScript "strict" mode, which constrains the language. Setting "strict" to "true" enables "alwaysStrict", but not the other way around. I'd remove "alwaysStrict" and go with "strict" as it covers more things.

quackware 3y ago

- Why include files, exports, and types in your package.json when you are just using ts-node to transpile on the fly? - ts-node is much slower than something like esbuild/tsx right? As long as you rely on your ide type checking or run type checking before deploying your app.

khalidx 3y ago
The "exports" and other sections are recommended things you'll need in your `package.json` file to support ESM. Sensible defaults. Also just points to an index.ts file (that you'll likely have in your project if you are developing a package). Also, this project can be compiled with `tsc` or a bundler, of course. In terms of speed, this should consistently start up an app or CLI in <3 seconds (depending on size of course).

rickcarlino 3y ago

I’ve found TSX to be a better alternative to ts-node. It seems to have more sensible defaults in 2023. https://github.com/privatenumber/tsx https://github.com/privatenumber/tsx

lloydatkinson 3y ago
I was about to say exactly this. If you’re writing Node scripts there’s no reason to use ts-node as tsx, by default, does the correct thing and works correctly with ES modules. Of course, Deno offers a better experience for scripts or programs.
- khalidx 3y ago
  I tried `tsx` but it didn't work for some reason (can't remember why right now). Also, if you've been using `ts-node` and feel comfortable with it, this setup should work for you instead of switching your toolchain.
  - privatenumber 3y ago
    tsx v4 was released a couple weeks ago which addressed many incompatibility issues. Hope you have a chance to give it another shot :)
    - khalidx 3y ago
      I definitely will!
vmfunction 3y ago
or esno, which is tsx with esbuild.
- lhnz 3y ago
  I'm using `esyes` [0] by Yehuda Katz and the logic is simple and it works very well. [0] https://github.com/starbeamjs/esyes https://github.com/starbeamjs/esyes

toastercat 3y ago

Also see TSM: https://github.com/lukeed/tsm https://github.com/lukeed/tsm

WolfOliver 3y ago

Agree it is a little tricky to get startet. But once configured, it helps a lot

jna_sh 3y ago

This is not a guide, it's three config files

khalidx 3y ago
You're right, but what guide is easier than "Just add the following files and run npm run dev. You'll be good to go!".
- bilekas 3y ago
  I'm personally against that belief as it doesn't really teach anything. Just adds a list of bootstrapping that you don't understand.
  - jenscow 3y ago
    There's only so much spoon-feeding that can be done. We already have so much information at our fingertips. If people just want to copy+paste it then mark a jira issue as complete, that's up to them. However, for those of us who want to understand - sometimes it's better to see a working example and pick at it.
  - codingdave 3y ago
    I find that almost all devs have a layer at which they don't understand what is going on. Everything we do is built on the shoulders of giants, as evidenced by how little we think about the 0s and 1s that are the actual end result of our work. So I don't see a problem with any dev having a line of non-understanding as they work. Some peoples lines are lower than others, but we all work that way. So it is all good.
    - bilekas 3y ago
      Absolutely, but don't call it a guide. When it's not.
    - chii 3y ago
      > how little we think about the 0s and 1s that are the actual end result of our work. but that doesn't mean you don't understand it. You can get away with not thinking about it - for example, the error correction algorithms and protocols in tcp, or memory access - and that's because the designers of those layers have thought hard and long about how to keep it from leaking. For js ecosystem, the designers (?) didn't think much at all. It is hobbled together rather haphazardly over time. Leading to the mess today.

pyrolistical 3y ago

this setup doesn’t work with node test runner. I had to tsc then node --test the built files. tsx also is missing the test runner https://github.com/privatenumber/tsx/issues/257 https://github.com/privatenumber/tsx/issues/257

e1g 3y ago
With tsx instead of ts-node, it works just fine - node --import=tsx --test __tests__/\*/\*.test.ts
- pyrolistical 3y ago
  Including failed tests?

ivanjermakov 3y ago

And if you publush it, imports are going to be from 'pkg/dist/foo'..

bovermyer 3y ago

In order to be a guide, I feel like it would need to explain _why_ each thing is there and what it does.

EdSharkey 3y ago

A gist, the digital equivalent of scribblings on a stained cocktail napkin, lays bare the great mystery. The great dragon is slain! His precious treasure is of no value whatsoever. Fellow scrounging raccoons, raise your chipped mugs and cracked cups! Let us toast to our fortune, we truly are the blessed ones.

w3news 3y ago

Why not using Node how it is designed, than ESM works great. For type checking on development, you can do it with ESLint and JSDoc in Typescript modus. You have the same type checking like you have in ts files. You can even import types from typescript files, like .d.ts Best of both worlds, no transformation of the code, and on development you have some help from Typescript.

vasergen 3y ago

> The experience of using Node.JS with TypeScript, ts-node, and ESM is horrible. So true, I really wandering if there was a better alternative, they essentially broke a lot of packages and I don't know how many dev hours will be put now to fix all of this, because so many tools are broken now. Additionally to that, they did some other not backwards compatible changes, like removing __direname in ESM, which is IMHO not the best decisions, why not for example just keep it as it is, but deprecate it and have a warning message.

khalidx 3y ago
I agree that the migration experience has been subpar! I dropped ESM migration of my packages 2-3 times before finally picking it up again and wrapping it up in a simple guide. Hopefully with the config I shared you’ll find that you can use all those out-of-reach ESM packages now! Also, I provided examples for getting __dirname and __filename -like behavior.
azangru 3y ago
> a better alternative Deno?

jampekka 3y ago

https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d...

khalidx 3y ago
Strong agree. This has caused a major rift in the Node ecosystem (and for its packages). All we can do is adapt and keep building. Using Node v20 (LTS) currently with the config linked in the parent post.

demurgos 3y ago

I always found it easier to avoid `ts-node` as it introduced a bunch of small compat issues. Since TS 4.5 and their support for `.mts`, I finally settled on just chaining `tsc --build && node ./build/main.mjs`.

khalidx 3y ago
I generally agree with your statement, but have found ts-node incredibly valuable especially when developing servers or CLIs where I want to start/restart the process many times without a build step every time.
- SahAssar 3y ago
  Node has a built in watch mode and so does tsc. So if you start both you should get what you want.
azangru 3y ago
And for development?
- demurgos 3y ago
  With TS, I get type checking in the IDE; I don't need to rebuild every few seconds. When I actually need to build and test, it's very fast (<2 seconds). I use Yarn workspaces/subprojects and TypeScript references with incremental builds so it's not really an issue. Here is the `package.json` [0] for a serialization lib I did, you can check the `scripts` section: it's very minimal and I'm quite happy with it. I'm an old Gulp maintainer, so for a long time I had heavy Gulp config with a lot of processing. Over the years I could get rid of it. ESM was the last thing holding me back; and now I'm so happy that I can just use a few simple commands. [0]: https://github.com/demurgos/kryo/blob/master/packages/kryo/package.json https://github.com/demurgos/kryo/blob/master/packages/kryo/p...
beepbooptheory 3y ago
or: `tsc --build --watch` and then just have another terminal to run.

dalore 3y ago

[flagged]

koolba 3y ago

Many people in this thread are rightly complaining that this does not answer the "why does this work". Having a working example is a good start for that though as at least you have a known target and as you change things (and break things), you can see what those options did. One problem with this guide that makes that trickier is that the tsconfig.json itself imports https://github.com/sindresorhus/tsconfig/blob/5c87dc118e057dc16fe1e62c990645000dbfaac7/tsconfig.json https://github.com/sindresorhus/tsconfig/blob/5c87dc118e057d... and overrides a bunch of values. So if you really want to understand what it's doing, you need to get rid of that dependency and inline / merge that config file. That would also add stability to your project as it's one less upstream dependency out of your control (and a big one at that as it controls how you entire project is built!). For example the imported tsconfig.json changes these: "compilerOptions": { // ... "module": "node16", "moduleResolution": "node16", "moduleDetection": "force", // ... "allowSyntheticDefaultImports": true, // To provide backwards compatibility, Node.js allows you to import most CommonJS packages with a default import. This flag tells TypeScript that it's okay to use import on CommonJS modules. "jsx": "react", // ... } But you wouldn't notice that if you just look at the gist. It'd just be a magic that you can write React code in a .tsx file. Clearly that has to be enabled somewhere.

btown 3y ago
https://documentation.divio.com/ https://documentation.divio.com/ is a good overview of the "four types of documentation" paradigm: tutorials, how-to guides, explanations, and reference have to all exist. One of my major gripes with the JS/TS ecosystem is that "explanations" are sorely lacking. See https://www.typescriptlang.org/tsconfig https://www.typescriptlang.org/tsconfig for the relevant documentation for tsconfig files. Tutorials are on the page, how-to guides abound on the wider internet (like the OP), and the linked TSConfig Reference and JSON Schema (used in code completion in IDEs) are together absolutely massive. But an explanation is missing! There is no official documentation about how different options interact to say: as I'm walking a file tree as the Typescript compiler, this is how I will interpret a certain file I encounter, what will be outputted, and how that will be interpreted by bundlers and browsers, especially in an ESM world. https://medium.com/extra-credit-by-guild/tsconfig-json-demystified-d8f333e578c1 https://medium.com/extra-credit-by-guild/tsconfig-json-demys... is in the right direction, but outdated as ESM has become much more popular in the past 3 years, and still organized by option (so it's already somewhat in the "reference" world). IMO even independent of documentation, the industry's move to ESM is problematic: https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d... describes many of the issues. But they're certainly exacerbated by good explanation-style documentation that helps people understand how ESM works under the hood!

paradite 3y ago

I am pretty sure "type": "module" doesn't work with React Native/Expo and jest (in 2022 last time I tried). If you Google the error you will get stackoverflow posts with hundreds of upvotes. And that's the main problem with using ESM - 3rd party library support. It is trivial to do hello world in ESM with Node.js, but try that with 10 dependencies and quickly you will be hit errors.

Rapzid 3y ago

Module resolution "bundler". ts-node --esm --swc Haven't really had any issues with this in a long time.

tuyiown 3y ago

Add eslint and jest to pull your hairs of you head. I managed to get it right last week, but I'm pretty confident that next upgrade I'll have to revise most of it.

rickstanley 3y ago
Have you considered using Vitest? Its performance has had a significant impact on my workflow and the workflow of my colleagues. It supports ESModules by default.
- tuyiown 3y ago
  Ah! thanks a lot, I'll give it a good look next round, but I won't have much difficulty moving from jest, because its old roots triggers too much unexpected and hard to anticipate constraints.

drtgh 3y ago

Node.js, TypeScript (compiled script...), ESM modules, versions, and the dependencies tree hell... You guys are adopting the masochism, the problem is that you are dragging the rest of us into that hell.

bovermyer 3y ago
I'm going through a special version of this hell right now at work. I'm updating old Lambdas that are on the node.js 12 runtime. Some of them have internal dependencies that just _no longer exist_, or aren't compatible with Node past 14. Meanwhile, all I had to do to update old Python Lambdas was just update the runtime itself.
- postalrat 3y ago
  https://www.google.com/search?q=python+version+hell https://www.google.com/search?q=python+version+hell
  - bovermyer 3y ago
    Note that in my original comment, I didn't say Python doesn't have version problems. I said my (specifically my) Lambda version migration problems were much worse with Node.js than Python. Also, I'm vaguely offended that you used a "let me Google that for you" reply as your sole comment. Did you really have nothing more intelligent to add than low-effort snark? Go back to Reddit.
    - postalrat 3y ago
      A lot of people have versioning problems in all languages. You said "Meanwhile, all I had to do to update old Python Lambdas was just update the runtime itself. ". You know that isn't always true in Python that you just update the runtime and nothing goes wrong.
      - bovermyer 3y ago
        True, but Node.js is far worse when it comes to dependencies and _their_ dependencies.

dangoodmanUT 3y ago

This is why I use bun now! It just works, NodeJS is such a shit show right now, feels like the python 2->3 move.

davidy123 3y ago
I tried to use Bun but it doesn't support some low level Node APIs properly, in my case for Playwright. Keeping an eye on it though, what I saw seeemed promising.
- sroussey 3y ago
  Make an issue. I did so for various compat issues and they are fixed now.
  - davidy123 3y ago
    There are already long running issues on this topic. https://github.com/oven-sh/bun/issues/2492 https://github.com/oven-sh/bun/issues/2492
jzig 3y ago
I've been curious about using Bun. Could you point to an example of something like Node backend code that's written in TS using Bun?

monooso 3y ago

I see (and have participated in) a lot of this "just copy this thing, trust me it works" type of content related to Node and TypeScript. It makes me wonder why Deno [1] still seems to be such a niche choice. Most of these headaches just go away. Does anyone here prefer Deno for new projects? And if not, why? [1] And Bun, although that's much newer.

mark_and_sweep 3y ago
Being using Deno for new projects for years now. Not looking back.
- robbywashere_ 3y ago
  What are the advantages of deno over node?
  - flohofwoe 3y ago
    Not the parent, but one very nice aspect is that an entire working Deno installation is just one file: the actual deno executable. ...when installing via homebrew on Mac you get 3 more files which look like shell-completion definitions: bin/deno etc/bash_completion.d/deno share/fish/vendor_completions.d/deno share/zsh/site-functions/_deno
    - e1g 3y ago
      Both Node.js and Bun are also single executables. Node.js doesn't (yet) transpile TS for you, and that's a single dependency away.
      - flohofwoe 3y ago
        Yeah I was confused that the Node installation directory was showing me 18k files in several thousand directories, but these seem to be global npm installs which npm seems to put into the node installation directory (which tbh is weird, I would expect those somewhere in my user directory).

davidy123 3y ago

I'm going to keep hitting reload on this page until someone solves some of the worst problems of my work life right now; getting a npm monorepo with typescript, eslint and jest working smoothly. Thank you to whoever(s) that is. I'm trying to make a public project, but building/developing with it is successive layers of sometimes-works voodoo that have nothing to do with the project goals. Somewhat compounded when members of nx (nee lerna) popped in to try to help, adding another layer of sometimes-works. As it is, DX depends on a fast computer to basically rebuild the whole thing each time, or running build & test in a dozen workspaces, because I haven't found any other reliable "workflow."

searchableguy 3y ago
We gave up and switched to vitest.
- flohofwoe 3y ago
  +1 for vitest :D I was amazed that it "just worked" after struggling for hours getting jest to work because of silly file extension problems (really... what's up with that... wouldn't that be easy to fix if the Node.js and Typescript teams would talk for 5 minutes and agree on one approach?)
- davidy123 3y ago
  I don't use Vite though. Aside from typescript, I'm trying to be as vanilla/unopinionated as possible, using Web Components for example. And there are hundreds of Jest tests I don't want to port.
  - flohofwoe 3y ago
    You can use vitest like a standalone testing tool, it will install vite as dev-dependency but you don't need to build your whole project around vite. In my case it was literally a drop-in-replacement for jest, done in two minutes and without a config file. A simple config file only was required a bit later when I added test- and coverage-reporting as junit.xml and cobertura format for Gitlab CI. Didn't even have to change a single line of testing code (I didn't use Jest's mocking magic in that project though).

resters 3y ago

I thought there were "presets" that NPM and Yarn knew about to do this kind of thing...

sirius87 3y ago

The current ESM experience makes it seem like decision-makers in the node.js project were wilfully oblivious to how large the TypeScript community was and how it was being used in node modules and projects. It really does feel like the maintainers focus was on JS and harmony with TypeScript's evolution was low on the priority list. Meanwhile anyone using an intersection of TypeScript with jest and any of sindresorhus' libraries when he flipped to ESM for his bajillion libraries immediately felt the downside and moved hard away from ESM. Imagine the mind-boggling hours lost just to get these export/import formats to glue.

madeofpalk 3y ago
I really enjoy frontend/node/typescript development. I roll my eyes whenever the HN-types complain about CSS or frontend development being a hellhole. Mostly the comments I see seem ignorant or impatient ("Why doesn't this thing work without be bothering to learn it?") However, the intersection of typescript, nodejs, and ES modules is consistently the most frustrating experience I ever have. Trying to figure out which magic incantation of tsconfig/esbuild/tsc/node options will let me just write code and run it is a fools errand. You might figure something out, and then you try to use Jest and then you descend into madness again. The biggest tip I can give people is to ditch ts-node and just use (the awkwardly named) tsx https://github.com/privatenumber/tsx https://github.com/privatenumber/tsx, which pretty much just "mostly works" for running Typescript during dev for node. The problem mostly seems to stem for all the stakeholders being pretty dogmatic to whatever their goals are, rather than the pragmatic option of just meeting people where they are. I really wish the Node, Typescript, Deno/Bun, and maybe some bundler people would come together and figure out how to make this easier for people.
- sirius87 3y ago
  Totally agree. It's doubly frustrating because a standard for authoring modules across browser and server platforms such as ESM is a good thing. But it's a bit arrogant to expect module authors across TS and JS ecosystems to ship overnight. Beginners may just turn to Deno or Bun simply because hundreds of coding tutorials and snippets no longer work. Or, when you finally get a TS config that works but then you import @aws-sdk/* or prisma seeds and then you really rip your hair out.

bearjaws 3y ago

Main reason I even tried bun out. Honestly 'just works', I've only had one issue so far and it was with a unpopular compiled module.

sroussey 3y ago
I love it. Had some issues with terminal stuff, now fixed. Just works, indeed. But I have a difficult time trying to get a project make to node/ts.
mst 3y ago
I'm really enjoying bun for my own stuff but tsx looks more promising for work projects.

solatic 3y ago

Having tried to wrangle all of this both professionally and for a side project, the link is an over-simplification. No, it won't "just work". Part of the problem is the fact that web browsers, Node.js, and other JS runtimes have slightly different needs and expectations. Part of the problem arises when you're trying to mix and match web code, Node.js code, and other JS runtime code in the same monorepo. There's no single magic-bullet configuration.

_nalply 3y ago

One problem I encountered with ESM TypeScript development on the browser without bundling: many Node packages aren't set up for that. You might ask why without bundling? Sometimes you just want to start something simple on the browser and compile to JavaScript on the fly. I tried the dev server from Modern Web [0], and I liked it. I program in TypeScript and the browser reloads whenever I save a file. Of course I could set up a bundler and for a small program waiting times are negligible. But I hate bundlers. I know it's irrational, but nowadays I program for fun so I think I should have the choice to reject bundlers. This fails for many Node dependencies. There is a conflict between CommonJS and ESM. I am not 100% sure that what I want to achieve is impossible without forking dependencies and making a small change. I even found a way to have a CommonJs and ESM polyglot, but this hack is extremely ugly. I named the hack modglot [1]. I don't think this is a good idea and I don't understand enough to propose something. I am somewhat dejected about the current state of TypeScript development for the browser and paused development. Now I am programming in Rust again just for fun, but if I return to TypeScript, probably I will try out Deno. [0]: https://modern-web.dev/guides/dev-server/getting-started/ https://modern-web.dev/guides/dev-server/getting-started/ [1]: https://github.com/nalply/modglot https://github.com/nalply/modglot

cantSpellSober 3y ago

Does Node.js plan to transpile TS out-of-the-box soon? (Picking up a legacy project, can't swap out for Deno or another runtime just yet)

khalidx 3y ago
This would be a nice direction for the Node community. I wish for this. Especially since so many other platforms are supporting it out of the box.

dackerlunghack 3y ago

[dead]

tommy_guo 3y ago

Sharing https://github.com/tommyguo/node_monorepo https://github.com/tommyguo/node_monorepo if this helps folks. It's a Typescript monorepo template with everything you need included. I'm currently using this setup to run multiple services on AWS.

preommr 3y ago

> Just add the following files and run npm run dev. You'll be good to go! This attitude just doesn't work for js ecosystem. I have some shell scripts, vim config files, etc. that I don't remember what they do, but I just copy over and they work. Coding projects are different; they break all the time. Especially with how fast the js/ts ecosystem works. One day, a crucial library just decides that it's changed something that doesn't work with the build process because there's so many variations of them that they can't possibly all be tested against.

bhouston 3y ago

I did some experiments myself and settled on this template repository: https://github.com/bhouston/template-typescript-monorepo https://github.com/bhouston/template-typescript-monorepo This has a lot of features that work well together: - TypeScript - ESM - Node.JS Server + React + Cli - Monorepository - Fast Incremental Updates Feedback welcome. I use this for about a dozen different projects now.

conaclos 3y ago

Some comments and suggestions: - `importsNotUsedAsValues` is deprecated [0] since TypeScript 5.2, in favor of `verbatimModuleSyntax` [1]. - I could set `module` to `Node16`. This automatically set `esModuleInterop` to true. - Also, to catch more issues, set `allowUnreachableCode` to false and set `strict`, `noImplicitReturns`, `noImplicitOverride`, `noFallthroughCasesInSwitch`, `exactOptionalPropertyTypes` to true. - Set `types` to the empty array `[]` to avoid loading unwanted types. - Enable `skipLibCheck` to avoid checking imported module types. - Not sure that `declarationMap` is still useful nowadays. TypeScript is now able to match directly against source files. - Enable `composite` that in turns enables `incremental` and `declaration` (declaration file emit). `composite` enables project references which is useful in a monorepo setting or to separate source and test files into two projects. See [2] - Enable `checkJs` to type-check JavaScript files To summarize: { "$schema": "https://json.schemastore.org/tsconfig", "compilerOptions": { "lib": ["ES2022"], "module": "Node16", "target": "ES2022", "outDir": "./dist", "composite": true, "sourceMap": true, "types": [], "isolatedModules": true, "resolveJsonModule": true, "skipLibCheck": true, "verbatimModuleSyntax": true, "allowUnreachableCode": false, "checkJs": true, "exactOptionalPropertyTypes": true, "noFallthroughCasesInSwitch": true, "noImplicitOverride": true, "noImplicitReturns": true, "strict": true } "include": ["./src/**/*.ts"], "exclude": ["./src/specific-file.ts"] } [0] https://www.typescriptlang.org/tsconfig#importsNotUsedAsValues https://www.typescriptlang.org/tsconfig#importsNotUsedAsValu... [1] https://www.typescriptlang.org/tsconfig#verbatimModuleSyntax https://www.typescriptlang.org/tsconfig#verbatimModuleSyntax [2] https://www.typescriptlang.org/docs/handbook/project-references.html https://www.typescriptlang.org/docs/handbook/project-referen...

rglover 3y ago

Hear me out: if you need to do this just to use a tool effectively, maybe it's a bad tool.

wruza 3y ago
We're open to suggestions!
- rglover 3y ago
  In this specific context: just use plain JavaScript with default args and your own, inline type checker functions. No need for stuff like this and you can customize type checks to your heart's content.

wruza 3y ago

Ah, I upgraded just yet, realized node 20 broke the way ts-node-esm loader works. Had to downgrade to 18, because there's no functionality I really need from 20. Also Vite complained when I tried node 19, because it requires <=18 && >=20 for some reason (probably good one). I'm maintaining a few pristine example projects to keep track of these ways and test them periodically. This iteration probably had the shortest lifetime. I didn't manage to develop even a single toy project before something got obsoleted again. Love this community. Looking forward to solve a handful of brand new issues with tsx. I wish there was some IDEish starter pack which you could install and start writing code anytime, without investigating issues with running a damn interpreter.

jb_hs 3y ago
My guess is node 19 isn't an LTS version and it's hard enough to maintain just the LTS versions. Probably a requirement that will save a lot of pain...

c-hendricks 3y ago

I've been trying to upgrade a couple of libraries we use internally at work to output CJS + ESM, from a typescript project, and have the output be 1-to-1 files (so, no bundling / rollup / whatever you want to call it). What a frustrating experience it has been. Using unbuild "works", but - For the life of me, I can't get unbuild to generate `.d.mts` files when my source files don't have `.mts` extensions. Luckily, when the library is used in a downstream project and a `.mjs` file is imported, TypeScript properly loads the `.d.ts` file anyways - When it comes to a downstream project, TypeScript doesn't seem to work with export maps. People say it does, but maybe because I don't have `.d.mts` files TypeScript is saying it can't find type information? It _does_ work with simple export maps, but if I say `'./': './dist/esm/'` so the downstream project doesn't have to manually import from `dist/esm` I see the issue - Using the "esm" module / moduleResolutions + converting my files to `.mts` + changing imports in the source to import the non-existant `.mjs` files results in a CJS bundle that tries to require a `.mjs` file, which unbuild has built with a `.js` extension, so it throws an error because it can't find the file. - For some reason unbuild mucks with the hashbang line in my _CJS_ `bin` script, the ESM one it doesn't touch Ugh.

moltar 3y ago
Try tsup it does just work unless your package is doing something funny. Then do a check with attw cli tool and it’ll report your compat mistakes with links to explainer docs.
- c-hendricks 3y ago
  That's what I tried using before and I had even less luck / had to do more fandangling, but thanks for the suggestion. Like I said, these are libraries whose "build" before was just `tsc`, there's nothing funny going on.
  - moltar 3y ago
    Share a repro I’ll sort you out. Gotten good at this bullshit :D

dimgl 3y ago

+1 to what one of the commenters is saying. You can skip all of this and just use `tsx`. I currently sponsor that project. That's how impactful it was on all of my development. I will say that it's kind of sad that Node.js has devolved into this.

apitman 3y ago

Typescript is a huge improvement over JS, but I never use it. My rule of thumb is that if TS provides a tangible benefit, I have too much complexity on the frontend.

kshahkshah 3y ago

Now add eslint and prettier :)

nop_slide 3y ago

Could someone succinctly describe the situation between node ts and esm? I’m not very familiar with the ecosystem and trying to understand what pain ports people are describing here in the comments.

awongh 3y ago

I just got started with a Next.js project coming from React with JS and…. another JS/TS rant incoming….. For an ecosystem that purports to be ready for professional use it absolutely boggles my mind that the tooling is stuck at this very amateurish level. Why isn’t there a ready preset for me to use ESM syntax with Next.js / Typescript? What’s wrong with the culture around Node/TS/JS tooling in general that it’s so consistently broken all the time? What the hell.

eddd-ddde 3y ago
Try QwikJS. It solves what you ask for, create a project and you are ready to go. Qwik feels so right to use, if you have 5 minutes you should read about it: https://qwik.builder.io/docs/concepts/think-qwik/ https://qwik.builder.io/docs/concepts/think-qwik/

SnoozingBoa 3y ago

Here comes a question what many of the people reading the comments are thinking: As of November 2023, what is the canonical way to set up a Node project with Typescript and hot reload? Minimal setup with least amount of configs and tooling. I am not after any other tools like Bun.

ycombinatornews 3y ago
Snowpack, parcel, esbuild. Minimal setup each. YMMV based on how you plan to distribute the build results (package, site or app) after.
- vlod 3y ago
  Maybe I'm not getting it, but I just set up an express.js app this last weekend with nothing much more than tsc (typescript) and ts-node. Do you need all that other stuff for a simple node app?
  - toastercat 3y ago
    You are getting it. Use less and smaller tools if possible. And if you're on Node 18, node comes with a watch mode built in that you can leverage. You can alternatively use esbuild to handle the TypeScript compilation since it is faster than tsc for that, and just keep tsc around for the typechecker.
- toastercat 3y ago
  Snowpack has been unmaintained for years now, and its homepage actively recommends people switch to Vite.

demondemidi 3y ago

"...for a few months." Until this github repo dries up the same way similar attempts at this have.

diamondfist25 3y ago

I really detest this JS dx. Ideally things are great — do ur frontend dev in js and backend in js. With TS added for better dx. Except 90% of the time ur fighting the configs of why its not importing/requiring U change from .js, .ts, .cjs, .mjs and nothing works