In China, we have using part of yarn for long, installation speed can be boosted with https://github.com/cnpm .
Yarn – A new package manager for JavaScript
431–440 of 486 posts
Re: Yarn – A new package manager for JavaScript
#432Earlier quoted context omitted.
Somewhat funny to have an FB employee complaining about overly centralized systems.
I used to find such comments funny until I began working for Big Name Corps myself and I realized how much one's personal philosophy could be inconsistent or sometimes even contradictory to the employer's philosophy. I make money by selling my skills to an employer despite inconsistent philosophies. I think it's like a chef that can cook meat for his/her guests although the chef has decided to refrain from consuming…
It's sort of related to the principal-agent problem ..
Re: Yarn – A new package manager for JavaScript
#433This is not a problem with the package manager. This is a problem with complexity. When did it start becoming reasonable for a front-end only part of the MVCC pattern to have 68 dependencies? Or for a transpiler like Babel to add 100k+ files? I'm sorry I just find it ridiculous that instead of taking a look at the disease (unbounded complexity), we are looking to engineer our way out of the problem by creating a pack…
What is your proposed cure for the disease?
Re: Yarn – A new package manager for JavaScript
#434Earlier quoted context omitted.
leftpad was a social issue. It's been solved by policy on the registry side stopping packages depended on by many others being unpublished.
If by "social" you mean bad decisions on settling a naming dispute, yes it was a social issue. That issue hasn't really been addressed publicly (the official policy still doesn't specify how disputes are decided by npm when no amicable agreement can be reached -- other than what essentially boils down to "we'll do what we feel is right"). The actual disruption however was solved by npm Inc disabling unpublishing (exc…
> If by "social" you mean bad decisions on settling a naming dispute, yes it was a social issue.
No, I mean someone retroactively removing a package others were using out of spite.
Re: Yarn – A new package manager for JavaScript
#435This may come off as a troll, but it's an honest question. I'm not a javascript guy. It's not a language I deal with at all. Why on God's green earth does it need as much tooling as it seems to have? Are people really making projects with dozens (hundreds? more?) of dependent libraries? Are there aspects of the language or runtime that reward multiple layers of configuration management? In short, what the hell is up…
This is a valid question coming from an outsider looking in. There are various packages that are extremely small (see leftpad and associated controversy). They often wind up in a slightly larger package, which itself winds up in a slightly larger package, which recurs until you finally wind up with one actual package of consequence that you're targeting. For example, Express (a very common Node.js abstraction) has 26…
41 dependencies isn't even that much.
Babel, the most popular transpiler, is 335 total dependencies, and it doesn't even do anything out-of-the-box. You need to add babel-preset-latest for 385 total dependencies if you want to actually transpile anything.
Want a linter? ESLint is 128 total dependencies.
Re: Yarn – A new package manager for JavaScript
#436Awesome! So far this is working great with a Dockerized Node application I have. Great job Facebook and the rest who contribute!
Re: Yarn – A new package manager for JavaScript
#437Earlier quoted context omitted.
Yes, it replaces the client, but it uses the same package repository and package format.
And thus could have been implemented as part of the existing client.
"Could have been implemented as part of the existing client" isn't the same as "Should have been implemented as part of the existing client".
I personally don't know much about either tool (don't do a ton of JS), but it's possible that fixing the existing client without either breaking backward compatibility or making it too complicated (multiple modes of operation) was too difficult or not worth it.
Also, I'm having a really hard time understanding the complaint about a new client. The value is in repository of reusable code, not the client. That you can use different clients with the same repository is a feature, not a bug.
Re: Yarn – A new package manager for JavaScript
#438yarn's immediate acceptance by the community over npm appears to be a wholesale rejection of semver and an embrace of dependency determinism. Every dependency is locked down to the patch level with yarn. Instead of major.minor.patch, it might just as well be a single incrementing number now.
Re: Yarn – A new package manager for JavaScript
#439Earlier quoted context omitted.
The benefit of what's happening in JS is that a lot of libraries are reasonably compartmentalized for a specific purpose. As an example: you _could_ have one SpockJS framework that gives you React + Redux + ReactRedux, but instead each of these libraries are separate so you can use them without each other. This allows you to, say, move from React to Angular without changing the state of your application. With everyth…
For testing it doesn't make any sense. I want a coherent and expressive framework that does everything. If I'm doing BDD I know that I will need everything from the start. And from the little that I have seen about jest..well it seems really a jest. I can't really think to do any serious BDD with that.
Even for testing I think it make sense. If you want to switch from Mocha to Jest and still use Chai for your assertions, you can.
Like I said, it's not better just different.
Re: Yarn – A new package manager for JavaScript
#440Earlier quoted context omitted.
I think the issue is that TS is non-modular and dictates javascripts reach. It behaves like no other tool and blocks others from working. Take something like React/Redux for instance, which are built around modern day javascript, but if you transpile any example on the official Redux page right now you will see TS bail out because it can't understand some of the syntax. Flow on the other hand solves one problem and s…
Not sure I understand. Can you give a concrete example?
You can only do as much as TS allows you to, unless you route through babel in a second pass. TS is a tool that controls to which extend you can use language features that are drafted. They do pick drafts here and there, but others they omitt, object spread for instance which is very common for Redux.
As i said, try to transpile this in TS: http://redux.js.org/docs/basics/ExampleTodoList.html
This is why they made Flow.