Hi, Jelle Licht writes: > Timothy Sample writes: > >> • Change the “Fix incorrect import semantics” comments to “Fix >> imports for esbuild”. To me, if TypeScript’s tsc likes the >> imports, they are correct TypeScript (despite the esbuild bug >> report). > > "Something a native speaker of English can make sense of" != "Proper > English", and in that same vein I don't think a commmon mistake with > workaround in place is not a mistake. > > I really don't care about what ends up in the codebase though, as long > as it is clear why we do what we do, which works out just fine with your > comment. Heh. You’re right: it’s not a big deal. Thanks for humouring me. :) >> The final result is still a little messy, but I don’t think we should >> hold this back any longer. It’s a significant step forward, and it puts >> us in better shape to improve things incrementally. >> >> WDYT? Let me know if I made anything worse! :) If the altered patches >> look good to you, I suggest you go ahead and push them. > > I still adressed some of Efraim's remarks, and pushed it to master just > now. Nice!! > There are quite some ways to go from here: > > * Get the 'binary' importer upstreamable (I will continue with this) > > * Properly support cross-compilation of Node and Node-packages > > I had a super quick look at this, but it seems that in building node, > you build intermediate tools that run on the host. Perhaps some our > x-compilation gurus can weigh in. > > * Make a Rome-based build system, once Rome does more than linting, to > help untangle the knot that is JavaScript-packaging Sounds pretty exciting! -- Tim