Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Will Trex avoid the shortcomings of npm? #35

Closed
mphelp opened this issue Jul 9, 2020 · 2 comments
Closed

Will Trex avoid the shortcomings of npm? #35

mphelp opened this issue Jul 9, 2020 · 2 comments

Comments

@mphelp
Copy link

mphelp commented Jul 9, 2020

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

  • Fellow JS developer
@buttercubz
Copy link
Member

@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

@t8
Copy link

t8 commented Jul 10, 2020

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."

@buttercubz buttercubz pinned this issue Oct 22, 2020
@crewdevio crewdevio locked and limited conversation to collaborators Feb 9, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants