How is building Typescript libraries for esm, cjs and dts with Rollup still breaking in 2023? I had a setup last year that worked perfectly fine, I copied it over to a new library and now tslib is being imported by relative path from node_modules? Why would that ever work?

You were building your own language and now spending time on this lame stuff? Damn

@retoor This is where I started, and I had quite a decent workflow before I switched to Rust where a seamless workflow for publishing packages is the norm. I expected that since my workflow made use of tools that didn't need to evolve much, it would continue to work after about half a year.

It just clicked to me that there wasn't actually any reason to use tslib because this was originally a JS script before I converted it to typescript for verifiability and publishing.

Turns out I had downlevelIteration enabled and targeted es3

Why are these the defaults? Why are these _ever_ the defaults?

@retoor I haven't forgotten about Orchid, I tried to convert the STL into a convenient format where some items are defined in Rust and some in Orchid and the two mix naturally both in source and in the resulting environment, and then I realized that one of my core assumptions was that overlain libraries may reference but not extend the previous layer. I'm now fixing the bugs caused and uncovered by this stretch of the concepts.

Once this is done I'll get cracking on a stream-based IO system, then bindings to Chumsky (the same parser combinator the interpreter uses) so that scripts can interact with the streams without the bottleneck of Orchid.

I don't know why other interpreted languages don't expose the interpreter's dependencies to usercode. It's STL functionality at a discount and streamlines the transition from power user to contributor.