You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ryan Dahl is the creator of Node. Two years ago he presented his regrets about it. He regretted how the package.json "allowed the concept of a 'module' to mean a directory of files" and created a centralized repository with not much clarity on where the dependencies live. JS on the web usually doesn't follow this pattern. Package.json also became bloated in his eyes.
Does Trex avoid these shortcomings?
It does seem like Trex has some centralization like the package.json (pro and con of extracting imports into one place)... but also has the same specificity of deno for imports.
@mphelp Trex is based on imports map, it uses commands similar to npm to make it more friendly for those who already know the nodejs environment. Trex downloads and saves packages in the cache as deno does and by using the file import_map.json you can use the name aliaces, Regarding the hosting of the packages this is extracted from deno.land/std, den.land/x and nest.land, we try to be the most neutral in this aspect and we also have support to install any package hosted in a repository
Though I'm not directly tagged in this thread, I think I should point out that Trex' import map file is only slightly comparable to a node package.json file. I took a look at the video you referenced, and yes, Trex does use an import map, but they only do this in an effort to make the developer experience easier when vendoring modules. package.json also includes many other fields that add to the "bloated" effect it has on the ecosystem.
I personally do not see any other way for them to go about implementing this while maintaining the smooth developer experience that they have. When choosing to vendor modules, I feel that this controversy would become relevant for any import system. One could even argue that dumping all of the imported modules into a single folder is a form of "centralization."
See here: https://youtu.be/M3BM9TB-8yA?t=584
Ryan Dahl is the creator of Node. Two years ago he presented his regrets about it. He regretted how the package.json "allowed the concept of a 'module' to mean a directory of files" and created a centralized repository with not much clarity on where the dependencies live. JS on the web usually doesn't follow this pattern. Package.json also became bloated in his eyes.
Does Trex avoid these shortcomings?
It does seem like Trex has some centralization like the package.json (pro and con of extracting imports into one place)... but also has the same specificity of deno for imports.
@RivierGrullon @buttercubz
The text was updated successfully, but these errors were encountered: