A lot of the current friction is caused by packages that have partially implemented their own node resolution algorithm or expect ./node_modules/.bin to contain all locally installed package binaries. I'm guilty of this myself, and I look forward to rectifying these mistakes.
-
-
Prikaži ovu nit
-
The node_modules folder works, kind of. It's easy to create packages that import dependencies they don't list. This lack of validation has made us lazy. Loading transitive dependencies is made possible by hoisting, so why list a dependency of a dependency yourself?
Prikaži ovu nit -
The amount of times I've seen developers just disable the no-transitive-dependencies rule in tslint/eslint is too damn high. "It works, doesn't it?" is a bad answer if it only works accidentally.
Prikaži ovu nit -
As someone who switches between two branches with different typescript versions multiple times a day, the install step is a problem. It takes too long and it's easy to forget. Big thanks to Jenkins for catching me using ts 3.4 features on our 3.2 branch. It's needless friction.
Prikaži ovu nit -
As a maintainer of a couple of internal libraries that contain multiple packages per repo, constraints are a godsend. No more problems if I update all angular packages and one open PR adds a new dependency on the previous version. This has already prevented so much bugs.
Prikaži ovu nit -
Is yarn 2 finished? Not by a long shot. The node_modules plugin needs to be polished, some dearly needed commands are missing (e.g. npm info) and it really really needs to be tested by more people with more environments and setups. Is it ready for more mainstream usage? YES!
Prikaži ovu nit
Kraj razgovora
Novi razgovor -
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.


he/him.
Web developer focused on Angular at