Blogged Answers: My Experience Modernizing Packages to ESM about marks-dev-blog-comments HOT 10 OPEN

I'm just in the process of configuring package exports for TS monorepo and you've saved me a lot of time with this article. Thanks!

from marks-dev-blog-comments.

I haven't had a chance to read the full thing yet as I'm currently in the middle of trying to fix a broken build of a yarn1 monorepo, but the rant section is 100% on base. I'm newer to js/ts, coming from a decade+ of PHP+composer framework development (and a smattering of C#), and build/package maintenance headaches have been absolutely shocking to me.

It shouldn't be this hard. I understand some of the problems, but it feels like there's nothing similar to the PHP-FIG that helped get PHP's frameworks, libs, and package management into some kind of shape.

from marks-dev-blog-comments.

It's a miracle anything about this ecosystem works at all.

I have been through a similar hell, but on a much smaller scale. It has been and still is ridiculous, nonetheless. Every time I observe the state of these tools in JavaScript, I have the same questions:
Is it worth it? What is the time period before all of this gets deprecated again?

Every year, a new package manager emerges. Instead of the JavaScript community trying to focus on the current tools and enhance them, they channel that energy into these new options.

I come from a PHP / JVM (Java, Kotlin) background, and I must say, that world is just better there.

from marks-dev-blog-comments.

Thank you for this writeup! Take some rest, the RSC burnout is real. Next’s ecosystem is driving everyone crazy with their dmiddleware, edge, server, client side

from marks-dev-blog-comments.

This is one of the best reads I've had this year. Thank you for documenting your processes; I learned so much. 🤝

from marks-dev-blog-comments.

A comment of support and thankfulness! I can totally understand the frustration and apathy when it comes to going on a path nobody has really ventured before. And I want to say thank you for doing all of the hard work for the community and educating yourself, as well as other engineers who will struggle with the same thing. Thank you!

from marks-dev-blog-comments.

Great article. For new versions, I would recommend just shipping Typescript. Good server-side runtimes like Deno and Bun already support TS OOTB, and anything that goes on the frontend goes through a bundle that, again, has support for Typescript. it saves so much headache not having to deal with typings, module formats, and all the other things you mentioned in your article, and just shipping some .ts files and letting the build tools deal with that as they wish.

from marks-dev-blog-comments.

I've wrestled with all this stuff so much, sometimes I'd feel so stupid for not understanding, but it's truly a mess. I ended up just giving up and going esm only. I could not get esm/cjs to coexist properly, there were typescript resolution errors all the time (I think it comes down to what you mentioned about there needing to be a type definition per bundle type).

I've also had to mostly abandon using any aliases (this includes typescript's baseUrl). If you do, you have to be very careful and have your bundler properly resolve them, then use a different separate tool to fix the types typescript emits and be sure they're both resolving to the same thing!!! If you don't your package will work, but when you try to use it the types will only half work, they won't all resolve properly, turning things into any and it's a very hard problem to track down.

from marks-dev-blog-comments.

I was ready and willing to pay someone a pile of money to fix our ESM nightmare, but now there's this! Thank you so much for doing it. I think it's the best thing ever to come out of Redux. :)

from marks-dev-blog-comments.