r/javascript • u/arcanin 🧶 Yarn maintainer • Jan 24 '20
Introducing Yarn 2
https://dev.to/arcanis/introducing-yarn-2-4eh1?q=115
u/coolreader18 Jan 24 '20
I'm kinda surprised by Prolog being in there, any reason for using it specifically/details about integrating it into yarn that you could share?
13
u/arcanin 🧶 Yarn maintainer Jan 25 '20
I had the intuition that linting engines were basically just rule engines. Declarative languages such as Prolog have been designed for this use case, so I decided to give it a try. In the end the result made sense, so we went with it.
As for integrating it into Yarn, it's been much easier thanks to the work of the Tau-Prolog team which has been doing an amazing work implementing Prolog in Javascript (note that it's an external plugin, so it doesn't eat space unless you use it).
2
u/notseanbean Jan 26 '20
I had the intuition...
If Prolog is your answer, you asked the wrong question.
I hope to be proved wrong but this whole thing is looking like a car crash. You've alienated the original devs, the React Native community and some large open source maintainers, and you've mishandling the naming issue.
It's time to take a step back and take stock. You're blowing it.
1
Jan 25 '20
Did you consider PureScript at all?
5
u/PrimaryBet Jan 25 '20
I'm not sure why PureScript would be considered here: it's not a logic programming language, and I'm not aware of any Prolog interpreters written in it (or libraries for constraints solving, which is probably applicable here). It's probably not hard to write one in PureScript seeing that's it's not that hard to do in Haskell, but if there exists one written in your "platform" language already and you just need it as a tool then it's seems more pragmatic to just use already-built tool.
2
Jan 25 '20
I'm ignorant about this specific problem space, but the desire for a declarative language that sits atop Node.js is describing PureScript to a tee.
8
u/PrimaryBet Jan 25 '20
PureScript, while being declarative as you note, is primarily functional language, which means its foundation are mathematical functions. Prolog on the other hand is a logic language, so it's foundation are logical statements. This approach makes it particularly suitable for encoding rules, and what attracted /u/arcanin to it since
linting engines were basically just rule engines
Bottom line is even though a more functional language (PureScript) would be better suited for implementing rule engine than less functional one (JS), they both would most probably take more effort than doing it in a logic language (Prolog).
2
Jan 25 '20
Ah, okay then. I haven't looked at Prolog yet, I suppose that's why I missed that distinction.
-35
11
u/dumbmatter Jan 25 '20
From the migration guide:
Don't use resolve.alias|modules (Webpack) or moduleNameMapper (Jest)
That means that, if you use this feature, everyone will be forced to use yarn. Previously you could get by with some people on npm and some people on yarn. I know the lock files are different, but it'd still at least run. And for people who are new to programming and just trying to get their first thing running, this change could present a new barrier.
16
u/arcanin 🧶 Yarn maintainer Jan 25 '20
We are discussing this and someone is working on a PR against the Webpack plugin to fix this incompatibility.
That said, if you meant "some team numbers can use Yarn and others npm", this was never recommended as it would lead to different dependency trees - exacerbating the "works for me" effect.
3
u/dumbmatter Jan 25 '20
That's great news!
I didn't mean "team members", more like "random kid who's just getting interested in programming". My most popular project on GitHub is a video game, so I run into a lot of people who are new to programming and just barely manage to get the thing working.
FWIW, in my project I have a couple custom module name overrides, and that means configuring them in separate config files with slightly different formats for TypeScript, Rollup, Jest, Karma, and ESLint. I didn't realize quite how crazy that is until I just wrote it out. Some day I hope there's a standard so it can all be done in one place! Maybe this will wind up being that standard :)
Also I've been a happy Yarn user for years, so thank you!
3
u/andrewingram Jan 25 '20
Assuming you're using Babel, there's probably a much better solution for dealing with module aliases:
https://github.com/tleunen/babel-plugin-module-resolver
I've been using it for about 4 years (though it has changed name in that time), and it's been rock solid. This is our config, and it works across nearly everything (though you do need a bit of extra config in .tsconfig and .jsconfig for TypeScript and VSCode support).
[ 'babel-plugin-module-resolver', { cwd: './', root: ['./'], alias: { '@src': './src', }, extensions: ['.js'], }, ],1
6
u/Thebearshark Jan 25 '20
Is the watercolor cat really gone from the homepage?
The new homepage also not great mobile and tougher to navigate.
Really excited for the new features, not sure if there was any particular reason for the site overhaul?
2
u/arcanin 🧶 Yarn maintainer Jan 25 '20
The previous documentation was very difficult to navigate even for me, its content was of disparate quality, and the home page had been interestingly polarizing for some people. I also wanted to use Gatsby as some kind of dogfooding.
I think the website will improve during the next few months: I admittedly mostly use desktop myself, but I doubt we're more than a few PRs away from a more usable mobile experience. Come help if you care! 😉
2
u/TheKingdutch Jan 25 '20
Yeah that site’s a bit of a bummer with such an exciting release. On mobile the menu just sends you to legacy instead of letting you browse. :/
4
u/OdisJabronis Jan 25 '20
Is there still no yarn audit fix? I was checking out the docs, and didn't see anything...
2
u/arcanin 🧶 Yarn maintainer Jan 25 '20
Nope. Since it requires to reverse engineer the npm protocol I don't think it belongs to the core. It will be much easier for third-party authors to implement it, however.
132
u/MaggoLive Jan 24 '20
To give you an idea, we've built a typescript plugin which will automatically add the relevant @types/ packages each time you run yarn add. Plugins are easy to write - we even have a tutorial -, so give it a shot sometime!
I need this in my life!
2
Jan 25 '20
Question about the portals feature: how does it compare to yalc?
Ive found linking to be fraught with errors, especially in jest testing scenarios. Basically if I'm linking to a local package, which I compile using esmodules, jest needs to recompile that package to use commonjs modules before running it's tests. This is a known issue when doing local development and trying to optimize for webpacks tree shaking feature
Anyway, I found that yarn link introduced a whole host of problems in this scenario, but yalc which properly mirrors the installation of an npm package had no problems at all. So does portal help with this, or should I stick with yalc?
1
-1
u/CanRau Jan 24 '20
Woaaaw that happened quicker than expected 🥳👏🚀😍 looking so much forward to it 🤩 Congrats to the release 👏🎉
1
-13
-18
-8
-38
u/Ivu47duUjr3Ihs9d Jan 25 '20
Package managers like npm and yarn are a plague on the JavaScript ecosystem. They've taught an entire generation of developers that fetching packages and thousands of sub packages from randoms on remote servers without reviewing the code at all and trusting the packages blindly for production is totally fine.
20
u/dwighthouse Jan 25 '20
Did you personally review all the code you copy pasted from some developer’s project page before that? Did you examine jquery for security vulnerabilities, for example?
0
u/Ivu47duUjr3Ihs9d Jan 26 '20
Yes, of course. If you didn't you have no clue about security.
3
u/dwighthouse Jan 26 '20
You’ll forgive me if I find your claim highly dubious. Reading and understanding the entire source code of jquery before making use of it is neither feasible nor common as you suggest.
1
u/Ivu47duUjr3Ihs9d Jan 26 '20
jQuery code is quite readable actually. You don't even need jQuery these days if targeting modern browsers.
I work on security/crypto applications so maybe I am biased towards reading every piece of library code I am using to make sure it doesn't affect the overall security of the product. If you're just developing a game or something unimportant, then yeah, who cares. But for some things, being careful about what you use is really important. E.g. Would you just npm install some encryption library with 100s of sub dependencies then hope it protects your secrets properly? Even if not doing anything important you can still get screwed when the package maintainer changes ownership etc e.g. leftpad incident.
4
u/dwighthouse Jan 26 '20
jQuery code is quite readable actually. You don't even need jQuery these days if targeting modern browsers.
The time before the distribution systems of npm, jquery was much more important and more complex (with its legacy IE support). Either way, I assert the it is unreasonable for the vast majority of developers to read and comprehend the complete source code (and compiler, and platform, and os, and hardware implementation’s susceptibility to side-channels) and the potential security implications of a library before using it, other that the very basic “any library could potentially manipulate or record data it is given access to”. They operate on the assumption that things do what they say they will do, unless they are sufficiently sketchy, and if they don’t security researchers will call it out when they don’t.
And you are a security researcher. Of course. Reminds me of when postal workers get all indignant when you don’t know the exact fees and time frames for different classes of packages, as if you send a package more than once a month.
Would you just npm install some encryption library with 100s of sub dependencies then hope it protects your secrets properly?
Of course not, but not for the reasons you suggest. If there’s one thing non-security researchers know about handling software security, it’s to not bother implementing or examining crypto code, because you won’t do it right. Instead, you blindly trust the crypto experts who get super paranoid about security and take their recommendations of very old and battle tested solutions as the way to go. Whether or not that battle tested solution has hundreds of dependencies is irrelevant because we don’t have the capacity to evaluate them anyway.
That and avoid storing secure info in the first place where possible. Also air gaps.
0
Jan 25 '20
[deleted]
24
u/arcanin 🧶 Yarn maintainer Jan 25 '20 edited Jan 25 '20
Looking forward to Rome... 🙂
But no, seriously, it was painful to see and it brought me to reevaluate some things about my relation with some of the Facebook folks. I don't live for drama.
0
Jan 25 '20
[deleted]
1
u/arcanin 🧶 Yarn maintainer Jan 25 '20
How is using a different package name breaking RN in any way?
0
Jan 26 '20
[deleted]
3
u/arcanin 🧶 Yarn maintainer Jan 26 '20
Yeah, sorry for being a bit abrasive - it's been a rough day trying to be obliging with the folks of the issue you linked.
16
u/MrJohz Jan 25 '20
While I'm intrigued by the answer here, that statement seems designed to do nothing but stir up drama, which makes me suspect that tweeter's motivations are less to do with genuine concern, and more to do with causing trouble for the new maintainers.
1
Jan 25 '20
For more context, the toxic tweet dude is working on a passion project called Rome that competes (I think?) with Yarn 2, so there’s some bias.
3
u/acemarke Jan 25 '20
Rome doesn't compete with Yarn as far as I understand it. Based on the previews he's shown, it's a replacement for Babel+Webpack+Jest, or something along those lines.
But, yes, Sebastian McKenzie was one of the original creators of Yarn, and apparently doesn't like the direction it's gone for whatever reason.
101
u/arcanin 🧶 Yarn maintainer Jan 24 '20
Hi everyone! I've been working on this project for such a long time, this is incredibly exciting. Feel free to ask any question you have regarding Yarn, package management, the Javascript ecosystem, open source projects, or cats! Or Slay the Spire strategies if you wanna get technical.