Node.js adds experimental support for TypeScript

Re:Node.js adds experimental support for TypeScript by sholladay on Thursday July 25, 2024 @11:21AM (#41069743)

You want to be forced to use a centralized registry? I don’t know. URL imports also enable fully isomorphic modules. I think you would enjoy the freedom of URL imports if the ergonomics were better. For example, it should just default to https:// so you don’t have to type that. Import maps also help a lot with this, definitely use them. But they could be even better by having first-class support for templating the module version into the URL so that the version can be stored separately, alongside the module name. Popular hosts with well-known URL structures could have their URLs automatically templated so you only have to specify the host and not the rest of the URL.

In other words, the tooling could be better, but the fundamentals of URL imports are sound, IMO.

[ Parent | on HN ]

Re:Node.js adds experimental support for TypeScript by zzo38computer on Thursday July 25, 2024 @12:51PM (#41070772)

I disagree. It should not default to "https://" (I think defaulting to local files would be better).

Furthermore, I think that it should be made so that the "hashed:" scheme that I had invented (in the Scorpion protocol/file-format specification document, although this scheme can be used independently of that) can also be usable.

And, popular hosts with well-known URL structures automatically templating also I would disagree, although it might do to allow any expressions in place of the string literals and then add functions for abbreviations of some of those URLs, if that would help (although I still think it is unnecessary).

[ Parent | on HN ]

Re:Node.js adds experimental support for TypeScript by johnny22 on Friday August 02, 2024 @04:20AM (#41137043)

yes, I would prefer to use a centralized registry indeed. However, that's not actually what i'm talking about here. Even just decoupling the import from the package is enough. You can already do this by by pointing a package in package.json to a remote tarball or git repo.

[ Parent | on HN ]