[LibertyBeta]

So, to me, this just looks to wrap the import map functionality with a nicer cli.

For the same number of times as in days I'm torn on wether this is good.

On one hand, it's a bridge for node people and adds some nice comfort tooling.

On the other, it means you don't get to really understand how packages and bundling are supposed to work.

I may just end up writing a post on this tonight.

[29athrowaway]

It also reintroduces one of the main problems of node back into deno. https://youtu.be/M3BM9TB-8yA?t=581

[tatef]

In my opinion, Trex is actually working against what npm introduced to Node. Though I don't exactly know what "main problem" you're referring to, I can say that:

1) Trex is supporting multiple module registries, not just one. (Thus not necessarily centralized) 2) Trex is not associated with one entity in particular. This means that they have no company dedicated to hosting modules in house (another reason that they aren't centralized) 3) Node's package.json included many other things than just imports. Using Trex is completely optional, and if you do use it, an import map does not hinder one's development workflow. In my opinion, it makes dependencies easier to manage.

[buttercubz]

not really since it is around imports map something native to deno, the purpose is to make it something familiar like npm

[29athrowaway]

npm should not be a model to be imitated. npm modules make security audits impossible.

[buttercubz]

Trex currently uses deno.land/std, deno.land/x, nest.land and any repository. nest.land provides a blockchain-based service, we just take the way npm is used for our CLI. Trex doesn't try to look for the same npm issues, we just take the import maps and create a tool to manipulate them in a friendly way for those who already know the nodejs ecosystem