14 ms·

Yarn's Future – v2 and beyond

380 points by arcatek 8y ago

Vinnl 8y ago
> your previous yarn.lock will be silently migrated I hope that's not that silent, because at that point, everybody who works on that project will have to upgrade as well. That said, shipping the light-weight POSIX-like shell will make it a lot easier for scripts to be multiplatform. That's the improvement I'm looking forward to most.
- arcatek 8y ago
  We'll make sure to add a notice at runtime to make it clear (plus, a consequent diff at review). Also note that we recommend using `yarn policies set-version` to enforce the version of Yarn used by everyone in your team with very little friction: https://yarnpkg.com/en/docs/cli/policies#toc-policies-set-version https://yarnpkg.com/en/docs/cli/policies#toc-policies-set-ve...
  - Vinnl 8y ago
    There's a feature I didn't know about - that's enormously useful, thanks! Now to remember applying that to all my different repo's...
sebazzz 8y ago
There appears to be a real movement to move from Flow to typescript. Is Flow dying?
- Vinnl 8y ago
  Well, TypeScript at least is growing enormously. Whether Flow dies or not is up to its authors, but I think TypeScript is pretty much unstoppable today.
- russley 8y ago
  There have been several projects that were flow based that have moved to TS. I think the real litmus test will be if React eventually either includes TS types or is rewritten in TS. Disclaimer: I work with TypeScript professionally.
  - acemarke 8y ago
    I'm pretty in tune with what's going on around React, and I don't see that one ever happening. The React team is _very_ busy already with work around Hooks, Concurrent Mode, and Suspense. There's no way they're going to pause development on implementing all these major chunks of functionality just to rewrite from one type system to another. I've seen Dan express some frustration with Flow's pace of development on Twitter a couple times, but beyond that, no indications whatsoever that React would be converted to TS. In the entirely hypothetical scenario that React _did_ get rewritten to another language, I have to assume it would be something like ReasonML (which was created by Jordan Walke, the original creator of React).
    - 52-6F-62 8y ago
      One of the benefits to TypeScript is that the codebase wouldn't need to be rewritten. A declaration file(s) could be included. There they could just declare types for all classes, methods, constants, etc. Similar to C header files. (This is how the DefinitelyTyped repository handles typings for untyped source repositories: https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped) Ex: JavaScript: app.js function app(arg1, arg2, arg3) { // does something return { key1: someStringValue, key2: someNumberValue, }; } TypeScript: app.d.ts declare type AppReturnValue = { key1: string, key2: number }; declare function app(arg1: string, arg2: string[], arg3: boolean): AppReturnValue;
      - acemarke 8y ago
        Given that React is already heavily invested in Flow types, there would be _some_ form of rewrite. And like I said, Flow is providing sufficient benefit for the React team right now, and their focus is on expanding React's capabilities. Changing type systems is not on their radar as far as I know.
- LaGrange 8y ago
  Facebook (excuse me, bunch of FB employees from the Flow team) says no: https://github.com/facebook/flow/issues/7365#issuecomment-454956694 https://github.com/facebook/flow/issues/7365#issuecomment-45.... Of course, that's exactly what I'd say if I was in charge of a dying project. Edit: but, their main codebase is in Flow, and that sounds like a mess to migrate, so I wouldn't be _too_ worried. It might slow down, but I doubt it will become unmaintained anytime before Facebook gets sued out of business :-P
  - kimsk112 8y ago
    I recalled when Microsoft employees and MVPs denied when Silverlight was dying. :-( I think the TypeScript momentum is too strong now.
    - LaGrange 8y ago
      I think Flow's in more direct trouble, but I wouldn't announce victory for TypeScript just yet. With wasm around the corner, things may (or may not, shrug) change significantly.
      - int_19h 8y ago
        Even with wasm, much as I'm looking forward to the Great JS Purge personally, it's not going to happen anytime soon - too much existing code and devices. JS will remain necessary on the front-end for at least another decade, and probably beyond that. So TS will still be necessary to make the pill less bitter.
- sephoric 8y ago
  I tried Flow and TypeScript out about half a year ago in a client project and Flow was kind of painful and difficult to use, the updates, bug fixes and new features weren't coming as often as TypeScript's were, and maybe 70% of people I talked to were using TypeScript instead of Flow. Since then it's more like 90% now, and the TS team seems to be adding and announcing features faster than before, whereas I haven't heard about any new features in Flow. Maybe they're there, I'm just saying I haven't heard about them. This is all anecdotal but from what I've heard, it's very common. This is a big reason I chose TypeScript in Autumn. Also, VS Code has become the de facto free editor of JavaScript projects with a full set of professional-grade IDE features across the board, and VS Code has first-class support for TypeScript but only plugin-level support for Flow. Since Monaco is simply extracted from VS Code, that means I got all VS Code's IDE features for free when I embedded Monaco into Autumn, all I had to do was set the language to "typescript" and it just works. All these free and serious benefits of TypeScript's ecosystem kind of point to this conclusion that I've seen on HN and elsewhere over and over, that TypeScript has already won and Flow is on its way out.
- mrspeaker 8y ago
  Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that... is there anything else on the horizon? [Edit: Nevermind: I went looking for the github issue about adding types as comments, and it turns out it's already supported by flow: https://flow.org/en/docs/types/comments/ https://flow.org/en/docs/types/comments/ - is there anything like this for TypeScript?]
  - _hardwaregeek 8y ago
    TypeScript works with JSDoc annotations: https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...
    - sephoric 8y ago
      Can confirm, have sometimes added /* * @type Foo */ above a type and VS Code assumed that type was Foo everywhere else in my project, as if I typed `foo: Foo` directly. Didn't even have TypeScript in the project itself, purely an IDE feature. Extremely well thought out and useful ecosystem.
    - deleted 8y ago
      [deleted]
  - Vinnl 8y ago
    Yes, TypeScript can do type checking on regular Javascript (annotated with comments) as well: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j...
  - lmm 8y ago
    If you're using Babel for compatibility with particular browsers then that can already handle TypeScript. What distinction are you drawing between a compile step that "strips away the type annotations" and one that does something else - what else is it that you consider compiling TypeScript to include? I have to ask what you're trying to achieve here. Moving types into comments just gives people who build without your typechecker the chance to break your code.
- jinder 8y ago
  Both yarn and jest have announced they're switching to TypeScript. A corporate like Facebook would never allow that unless there was an internal shift in direction. I'd consider flow dead.
  - bouncing 8y ago
    > A corporate like Facebook would never allow that unless there was an internal shift in direction. Sure they would. Flow has nothing to do with Facebook's business strategy, or its marketing campaigns, or even its corporate strategy. I'd be surprised if anyone on VP or higher even knows what it is. Insofar as "NIH" wins at big companies, it's when there's a business motive to promote a certain technology or FUD about what other technologies might exist. But engineering team A deciding not to use engineering team B's tools despite working at the same company? Happens all the time.
    - venturin 8y ago
      Engineering VPs very much know about it.
- ng12 8y ago
  Flow really shines when you have a large, untyped codebase and want to incrementally add types to it. If you're starting a new project (or rewriting one) TypeScript is the more sensible choice. By nature Flow is going to be used less and less over time.
  - noir_lord 8y ago
    For people now thinking well we have a large untyped codebase..damn. You can turn typescripts type inference on on a regular js file. https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j...
- agentultra 8y ago
  I'm curious as to this trend as well. I've read the justifications for it in each case and in this particular one I don't get it. Isn't Flow more concerned with soundness than intellisense? Has TypeScript caught up with Flow in this regard? Perhaps it's because I prefer to do my work in strongly typed, pure FP languages where I can but I work professionally with JS and have been investing in Flow there for over a year now. While Flow is still not exactly great it can at least mimic exhaustive pattern matching and catches most unsafe type errors without getting in the way of common JS patterns too much. The reason the yarn maintainers are giving is because they want more contributors? What advantage will that have if TypeScript isn't catching the errors you used to be able to catch or don't know about yet? Curious to know if it's worth migrating over to TS without sacrificing anything other than the minor inconvenience.
  - nicoburns 8y ago
    > Has TypeScript caught up with flow in this regard I think the answer is: it's very close. It's still a little behind flow on soundness, but it's now close enough (if you enable strict mode, which you should!) that you're unlikely to notice the difference. The TS type system is very impressive. It can't do everything that the functional languages can do, but it can do some things that they can't, and importantly it's still improving rapidly. You may be interested in the roadmap/changelog page: https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap
- whatever_dude 8y ago
  The writing has been on the wall for a very [1] very [2] long [3] time. Facebook and some consumers of their ecosystem have been holding the fort, but it was inevitable something like this would happen. 1: https://npm-stat.com/charts.html?package=babel-core&package=typescript&package=flow-bin&from=2015-01-01 https://npm-stat.com/charts.html?package=babel-core&package=... 2: https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F0n50hxv,facebook%20flow%20%2B%20flow%20language%20%2B%20flowtype,%2Fm%2F0hjc5m0,%2Fm%2F03yb8hb,%2Fm%2F0h52xr1 https://trends.google.com/trends/explore?date=today%205-y&q=... 3: https://developers.slashdot.org/story/18/11/25/017227/microsofts-typescript-dominates-in-state-of-javascript-2018-report https://developers.slashdot.org/story/18/11/25/017227/micros...
- bluepnume 8y ago
  I maintain PayPal's cross domain suite of libraries [0] and I'm fully intending to drop Flow for TS. The single thing I'm waiting for is https://github.com/Microsoft/TypeScript/issues/21699 https://github.com/Microsoft/TypeScript/issues/21699 since we use a fair amount of custom jsx rendering [1]. That's the one main thing (for me) that Flow is way stronger at right now. [0]: https://medium.com/@bluepnume/introducing-paypals-open-source-cross-domain-javascript-suite-95f991b2731d https://medium.com/@bluepnume/introducing-paypals-open-sourc... [1]: https://medium.com/@bluepnume/jsx-is-a-stellar-invention-even-with-react-out-of-the-picture-c597187134b7 https://medium.com/@bluepnume/jsx-is-a-stellar-invention-eve...
Aeolun 8y ago
I’m glad that Yarn will continue. Npm has improved, but it’s still less pleasant to work with than yarn (which basically always does what I expect, not so for npm).
- h1d 8y ago
  Which part of npm acts unexpectedly?
  - coding123 8y ago
    We switched around June last year to yarn because git URL dependencies on branches was broken in npm. It would choose incorrect commit ids inexplicably. Beyond that dependency upgrade time is faster.
  - dhritzkiv 8y ago
    Not that this is a showstopper, but I have issues with the package-lock.json file where the `resolved` field (the package's registry URL) constantly flip flops between http and https protocols, depending on which machine I'm on (home, work, or docker container), whenever I run `npm install`. Sounds not so bad, but it becomes a mess in git, and causes any docker build caches to become invalidated.
    - scrollaway 8y ago
      That sounds pretty bad and I'm not so sure it's a npm bug. Do you have a diff of the change in question? Is it on the npm registry or a custom one?
      - dhritzkiv 8y ago
        It's on the npm registry, affecting the npm client: https://npm.community/t/some-packages-have-dist-tarball-as-http-and-not-https/285/51 https://npm.community/t/some-packages-have-dist-tarball-as-h...
    - jwalton 8y ago
deleted 8y ago
[deleted]
CGamesPlay 8y ago
> The log system will be overhauled - one thing in particular we'll take from Typescript are diagnostic error codes. Each error, warning, and sometimes notice will be given a unique code that will be documented - with explanations to help you understand how to unblock yourself. Why do programmers love error codes? As an end user, they are useless indirection to me and the only way this would even be tolerable is if the explanation was printed directly next to the error code, so why bother? Is it code quality, since you don't have to write a long error message when you emit a similar error? But doesn't that have the drawback of encouraging error code reuse when it might not be appropriate? [append] Thanks for the replies! I guess I could understand error codes for search ability that also provide information about the problem specifics. Counterexample: $ yarn add foo Error YARN1001: Incompatible peerDependencies. $ yarn explain YARN1001 # Some longer text about how two of my modules have # incompatible peerDependencies Better example: $ yarn add foo Error Yarn1001: Incompatible peerDependencies. * my-package@1.0.0 |-* foo@1.0.0 |-* bar@1.0.0 |-* left-pad@1.0.1 (peerDependency of bar@1.0.0) |-* left-pad@0.9.0 (peerDependency of foo@1.0.0) $ yarn explain YARN1001 # Some longer text about how two of my modules have # incompatible peerDependencies
- lost_my_pwd 8y ago
  Humans are not always the consumer of error output. Distinct error codes simplify parsing and eliminate ambiguity. It also makes it easier for developers look up a specific error in the documentation, assuming it's been documented.
  - dmix 8y ago
    It's also easier for a (technical) user to reference they got error 1018 than copy & paste "An index signature parameter cannot have an accessibility modifier." Especially in titles and when referencing it multiple times within a body of text.
  - talltimtom 8y ago
    How does an error code make it easier to look up an error? The workflow is either “get error, google it”, or “get errorcode google it”. In both cases the docs will be the top hit. If we where talking 20 years ago I might agree, but I really can’t see the argument with todays tooling.
jcolella 8y ago
The addition of vulnerability scanning was the only reason our company switched back to npm from yarn. Other than that, yarn offers a great experience
- symlinkk 8y ago
  Yarn has this too (although it uses the NPM audit database): `yarn audit`.
  - coolreader18 8y ago
    Oh, I didn't know that! Here's some resources about it if you haven't heard of it either: documentation; https://yarnpkg.com/lang/en/docs/cli/audit/ https://yarnpkg.com/lang/en/docs/cli/audit/ original feature issue: https://github.com/yarnpkg/yarn/issues/5808 https://github.com/yarnpkg/yarn/issues/5808 release comment in that issue: https://github.com/yarnpkg/yarn/issues/5808#issuecomment-441989817 https://github.com/yarnpkg/yarn/issues/5808#issuecomment-441...
mydpy 8y ago
For the uninitiated / confused, this refers to yarnpkg, the JavaScript dependency manager, not (Hadoop) YARN, the cluster manager.
draw_down 8y ago
At this point I don’t see how it’s clearly better than npm, and having two tools is not great.
scrollaway 8y ago
Very happy to see yarn.lock will finally be a proper format that won't need its own parser. YAML subset is a pretty good choice, though I think canonicalized, indented JSON would be a better choice for this use case. Incidentally that's what npm uses as lockfile, I wonder if there's room to have the two package managers share the format (or even share the file itself). Very excited to see shell compatibility guarantee in scripts as well. Using environment variables in scripts is a pain right now. Finally one of the biggest news is the switch from Flow to Typescript. I think it's now clear that Facebook is admitting defeat with Flow; it brought a lot of good in the scene but Typescript is a lot more popular and gets overall much better support. Uniting the JS ecosystem around Typescript will be such a big deal.
- aylmao 8y ago
  > I think it's now clear that Facebook is admitting defeat with Flow. It sounds to me more like they're testing the waters. They're definitely opening up, with the whole Jest and create-react-app supporting it, but as far as using it themselves would this be the first project to be migrated?
  - basil-rash 8y ago
    Jest is migrating to typescript: https://github.com/facebook/jest/pull/7554#issuecomment-454358729 https://github.com/facebook/jest/pull/7554#issuecomment-4543...
    - aylmao 8y ago
      Oh, gotcha! Missed that comment.
  - scrollaway 8y ago
    Jest is getting migrated to Typescript as well, not just adding support for it. And then there's... whatever this is: https://twitter.com/jamiebuilds/status/1064649666275340288?lang=en https://twitter.com/jamiebuilds/status/1064649666275340288?l...
talkingtab 8y ago
I'm curious as to why yarn instead of contributing to NPM? I am aware that yarn was the inspiration for many improvements for NPM by providing an alternative, but going forward do we need two systems? Is the plan for yarn to be compatible with NPM and package.json?
- spricket 8y ago
  From what I've heard, the Yarn codebase is much cleaner than NPM. If anything, I think it would make more sense to migrate NPM over to yarn
- acemarke 8y ago
  Yes, having competition here has clearly benefited the ecosystem. I wrote a recent comment comparing the history and goals of Yarn and NPM: https://news.ycombinator.com/item?id=18950012 https://news.ycombinator.com/item?id=18950012
- whatever_dude 8y ago
  I've been using both for a while and I'm happy with their decision not to try and be "compatible" with NPM. I'm also pretty happy with using Yarn only - things are just faster and in reality make a little bit more sense.
yaseer 8y ago
The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winning' has been fast, and to everyone's benefit.
- ianwalter 8y ago
  Maybe it's a benefit when moving from Flow, but personally, I would rather have JS projects spend that time adding more tests than converting to static typing. Edit: changed strong to static.
  - janpot 8y ago
    sounds like their primary goal is 'attract more contributions' rather than 'strengthen the type system'.
  - jakelazaroff 8y ago
    Static types are a form of test!
    - lucisferre 8y ago
      They are a compile time contract at best, they are nothing like a test.
      - mort96 8y ago
        A lot of tests end up testing things which would've been caught by the type system. Static and strong typing doesn't make tests in general unnecessary, but it does mean you don't need quite so many trivial tests.
      - azangru 8y ago
        They are checking the shape of inputs and outputs, making it unnecessary to test that a function returns a value of a particular type or that this value has particular fields. They make sure you don't make stupid mistakes, leaving it up to you to test really valuable bits of logic.
juancampa 8y ago
If package.json is already in JSON format, why not use the same for yarn.lock? Honest question, there must be a good reason.
- arcatek 8y ago
  We want the lockfile to be easy to review by humans. In our experience, JSON doesn't quite fit the bill once you reach a critical mass of data. Our lockfile format worked fine for the past three years (bar the unfortunate YAML incompatibilities that we're about to fix). Don't fix what isn't broken :)
- slobotron 8y ago
  Too bad it's not package.yaml or package.js so that we can include comments and document our dependencies....
misiti3780 8y ago
> The codebase will be ported from Flow to TypeScript. To understand the rational please continue reading, but a quick summary is that we hope this will help our community ramp up on Yarn, and will help you build awesome new features on top of it. Another major project moving from flow to typescript
- tonyhb 8y ago
  This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues. I'm a little disappointed and feel as though, similar with Kube vs Swarmkit, the worse technology is winning.
  - Normal_gaussian 8y ago
    This is certainly how I feel; there are large parts of my codebases that I don't think will convert well if I was to change, where we leveraged flow to great effect. However I certainly take the point that flow has been developer hostile. When we have had issues it has been impossible to get a response (here is a demo, is this a bug or in the pipeline?). Though flow is v0.91 and Typescript is 3.2, i don't know if i can really fault them that much? I don't trust TS, they are too much 'move fast and break things'.
    - WorldMaker 8y ago
      Typescript has been moving fast, but they haven't broken that many things. The API and Language Server have changed obviously four times from a semver perspective, but in general the language itself has been extremely stable with great backwards compatibility, and most of the type system strictness additions are behind opt-in flags making upgrades usually as gentle as you prefer them to be (depending on your attitude to strict type checking). (I had projects that started with TS < 1.0 and they all still parse and compile today, albeit with tons of lint warnings, particularly to use a better module system than AMD with pre-ES2015 TS imports, and all sorts of new type strictness options to turn on to make them all the more type safe.)
  - 8y ago
misiti3780 8y ago
serious question, if you are starting a new project today why would you choose to use npm over yarn?
- azangru 8y ago
  Because npm is a standard (default) package management tool that comes with node. After getting `package-lock.json` and `npm ci`, I would rather wonder why choose yarn instead of npm.
  - MehdiHK 8y ago
    "npm ci" deletes node_modules directory every time. Try using that when you depend on some native modules. :(
    - azangru 8y ago
      I thought `npm ci` is more suited for ci machines, where it's crucial that packages are pinned to specific versions. For local development, I just npm install. Perhaps with no-save option in order to avoid updating package-lock. Works fine.
  - eknkc 8y ago
    Because I don’t trust it. Had to do rm -rf node_modules too many times with npm.
- ariabuckles 8y ago
  Because it comes standard with most node distributions and is pretty good. It coming standard means one fewer dependency for everyone on the team to install, which is important on my current team where roughly half are backend- or mobile-only. I like both yarn and npm, and yarn would have some benefits for us, but probably not enough to counter the extra effort onboarding other devs. npm still has some pain points, but I’ve ran into a few pain points on yarn too. And I think there being multiple projects here has helped the ecosystem. npm is also doing some neat feature development (npm audit). Also, the npm team is fantastic, whereas when I adopted yarn early on they dismissed the issue I opened about yarn not working for my setup. They’re a good team, but that lowered my confidence that I’d be able to get through any obstacles while using it. It’s still a fantastic tool though.)
towaway1138 8y ago
Yarn has over 1500 open bugs. Rather than working on changes, it'd be nice to stop and address these.
- arcatek 8y ago
  Most of those have been fixed a long time ago, but we simply don't have the resources to triage them. This effort we start is in no small part to decrease the number of issues that will be created by empowering the users to unblock themselves* and solidifying Yarn's codebase. * You wouldn't believe the number of issues that are simply about things working as they should - we can't really blame their authors because it can be quite hard to find the right paragraph in the documentation, but it's extremely taxing on a small team. Similarly, we often have issues created against older releases, or without reproducible test case.
  - towaway1138 8y ago
    I noticed the issue count while using yarn for the first time yesterday. It encountered a fatal error (Disk Quota Exceeded) and then proceeded blithely on. It's only one data point, but doesn't inspire confidence.
- moogly 8y ago
  And npm had 2166 at the time they archived their old GitHub repo, moved over to npm-cli (with issues disabled), and have all their issues in a Discourse forum, so you can't get an overall count, nor any connection to PRs and commits. So I'm not sure you can glean too much from just looking at an issue count in isolation.
mderazon 8y ago
> Writing posix command lines inside your scripts field will work regardless of the underlying operating system That is very nice. No need to install other dependencies just to do 'rm -rf'
- arcatek 8y ago
  Note that this is mostly about the command line syntax, not so much the commands themselves which will be executed just like now. That being said, maybe we'll offer some builtin as well (possibly in a similar way to what CMake offers?[1]). That would be worth an RFC later on :) [1] https://cmake.org/cmake/help/v3.2/manual/cmake.1.html#command-line-tool-mode https://cmake.org/cmake/help/v3.2/manual/cmake.1.html#comman...
jclay 8y ago
Since it seems the devs are here answering questions: Which lightweight shell will be used on Windows? Does it also bundle standard unix tools (if a script pipes to grep or less for example)? How will paths be translated on Windows? I’ve attempted something similar recently and had to do a fair amount of regex magic + using cygwins built in path translation utility to preprocess commands. Curious to see if there’s a better way to solve that.
- arcatek 8y ago
  > Which lightweight shell will be used on Windows? Does it also bundle standard unix tools (if a script pipes to grep or less for example)? It will be in-house, and very basic. We don't intend to rewrite bash, just to provide the basic experience that is usually needed when adding script into the `scripts` field. For more complex needs we'll simply offer a way to opt-out and use the native shell, or to call Node scripts. > How will paths be translated on Windows? The current Yarn tries to do this by using the `path` native module. It's quite error-prone since backslashes tend to appear in the worst possible places. For the v2 I plan to work with all paths in a posix style, and convert them into Windows paths right before they reach the filesystem (which is similar to what Cygwin does, as you mentioned). It would be a bit slower on Windows, but massively simpler in the codebase.
  - exogen 8y ago
    I'm assuming that lifecycle scripts (and scripts called by lifecycle scripts) in particular will still need to use common Windows-supported syntax? Even if the devs of the package are guaranteed to be using Yarn, people installing the package might still be using npm. So I assume some caveats apply to some scripts, right? p.s. I love Yarn :)
    - arcatek 8y ago
      The `postinstall` scripts would likely be better off without using those features, indeed. But in the end, your packages would be better off without `postinstall` scripts anyway ;)
symlinkk 8y ago
I've got to say I'm not a big fan of some of these changes and I think they're biting off more than they can chew. > Writing posix command lines inside your scripts field will work regardless of the underlying operating system. This is because Berry will ship with a portable posix-like light shell that'll be used by default. > Scripts will be able to put their arguments anywhere in the command-line (and repeat them if needed) using $@. Similarly, scripts will have access to $1, $2, etc. If you use either of these features your package.json will no longer work with NPM. Maybe they should call it yarn-package.json? > Starting from Berry, we made it an explicit goal that each component of our pipeline can be switched to adapt to different install targets. In a way, Yarn will now be a package manager platform as much as a package manager. If you're interested into implementing PHP, Python, Ruby package installers without ever leaving Yarn, please open an issue and we'll help you get started! Noooo, god no. Package management is a gargantuan, complicated task, and these languages all have their own solutions already. That being said, it's cool that they're rewriting it in TypeScript.
- maw 8y ago
  I don't see the need for PHP, because composer is one of the few things I like about it. And I don't know enough about Ruby to have an opinion there. But something for Python that actually works? Yes, please!
  - nhanb 8y ago
    For python we've been using poetry[1] at work. Dep resolution is a bit slow but otherwise it works well enough, definitely a saner choice than pulling in a completely different stack just for one tool. [1]: https://poetry.eustace.io/ https://poetry.eustace.io/
- arcatek 8y ago
  > If you use either of these features your package.json will no longer work with NPM. Yes and no. In the case of the `postinstall` script (which might indeed have to run on npm setups) you might want to refrain using those features. In any other case you simply won't use npm if you use them, because those are local scripts that only you and your team will use - and regardless of those features you should all use the same package manager anyway. > Noooo, god no. Package management is a gargantuan, complicated task, and these languages all have their own solutions already. We won't spend much time on it ourselves - as you mentioned other solutions exist and we have to pick our fights. Still, I believe this is a necessary move if we want to make our codebase clear and easy to contribute to. It's not so much about Yarn supporting everything than it is about making sure that we don't end up with a monolithic system hard to maintain.
spullara 8y ago
If you use the yarn cli and have tried the npm cli recently, why do you still use yarn? Are there big gaps that you find that NPM has failed to close?
- exogen 8y ago
  Unfortunately npm is probably the biggest source of my daily development frustrations, even on the latest version. I still come across bugs (that are definitely in npm itself) that have been around absolutely forever, like: > npm ERR! cb() never called! It sometimes gets its primary purpose, dependency resolution, wrong. I'll give it a perfectly reasonable package.json to install, which it will do, and then `npm ls` will still error with "missing dependency!" in some package. This should not be possible. Related, it will put packages from the flattened tree in the wrong place. I can have a dependency (that other dependencies need, specified in their peerDependencies) specified in my top-level package.json and bafflingly, npm will still move it from top-level node_modules into the node_modules of something else that happens to use it, breaking the peerDependencies I was trying to satisfy. On the install process: even if the total time to install is roughly on par with Yarn, I find that Yarn is much smoother. Whatever they're doing, they're yielding the CPU a lot more, and the result is I can actually work while it installs. npm meanwhile doesn't yield much during install and slows the whole system to a crawl. Some npm commands are extremely neglected. The "success" message printed by one of the user/permissions related commands is simply: {} Lastly, I will leave this terrifying comment here: https://github.com/npm/npm/issues/16528#issuecomment-307540010 https://github.com/npm/npm/issues/16528#issuecomment-3075400... – note this comment was left 2–3 years after receiving $10M in funding. I don't blame them for being one-upped by Yarn at every turn, but they still fail to get the basics right, let alone innovate on things.
- coolreader18 8y ago
  Kind of ridiculous, but yarn's CLI just feels better. It's a bit simpler, `install` doesn't really seem like an "add to package manifest" command word, there's the `global` subcommand for managing global command-line tools vs `-g`/`--global`, and no command aliases, which I like more for some reason. For me it's mostly personal preference; ergonomics would be the key difference for me. Plus, the upcoming stuff mentioned in this issue has got me excited! Edit: also, in my experience using npm for some little stuff recently, yarn is still faster installing packages. Edit2: I also like the ability to run scripts/commands from the base level of command, e.g. `yarn start`, `yarn webpack --mode production`, `yarn build:web`

380 points by arcatek 8y ago

> your previous yarn.lock will be silently migrated I hope that's not that silent, because at that point, everybody who works on that project will have to upgrade as well. That said, shipping the light-weight POSIX-like shell will make it a lot easier for scripts to be multiplatform. That's the improvement I'm looking forward to most.

arcatek 8y ago
We'll make sure to add a notice at runtime to make it clear (plus, a consequent diff at review). Also note that we recommend using `yarn policies set-version` to enforce the version of Yarn used by everyone in your team with very little friction: https://yarnpkg.com/en/docs/cli/policies#toc-policies-set-version https://yarnpkg.com/en/docs/cli/policies#toc-policies-set-ve...
- Vinnl 8y ago
  There's a feature I didn't know about - that's enormously useful, thanks! Now to remember applying that to all my different repo's...

sebazzz 8y ago

There appears to be a real movement to move from Flow to typescript. Is Flow dying?

Vinnl 8y ago
Well, TypeScript at least is growing enormously. Whether Flow dies or not is up to its authors, but I think TypeScript is pretty much unstoppable today.
russley 8y ago
There have been several projects that were flow based that have moved to TS. I think the real litmus test will be if React eventually either includes TS types or is rewritten in TS. Disclaimer: I work with TypeScript professionally.
- acemarke 8y ago
  I'm pretty in tune with what's going on around React, and I don't see that one ever happening. The React team is _very_ busy already with work around Hooks, Concurrent Mode, and Suspense. There's no way they're going to pause development on implementing all these major chunks of functionality just to rewrite from one type system to another. I've seen Dan express some frustration with Flow's pace of development on Twitter a couple times, but beyond that, no indications whatsoever that React would be converted to TS. In the entirely hypothetical scenario that React _did_ get rewritten to another language, I have to assume it would be something like ReasonML (which was created by Jordan Walke, the original creator of React).
  - 52-6F-62 8y ago
    One of the benefits to TypeScript is that the codebase wouldn't need to be rewritten. A declaration file(s) could be included. There they could just declare types for all classes, methods, constants, etc. Similar to C header files. (This is how the DefinitelyTyped repository handles typings for untyped source repositories: https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped) Ex: JavaScript: app.js function app(arg1, arg2, arg3) { // does something return { key1: someStringValue, key2: someNumberValue, }; } TypeScript: app.d.ts declare type AppReturnValue = { key1: string, key2: number }; declare function app(arg1: string, arg2: string[], arg3: boolean): AppReturnValue;
    - acemarke 8y ago
      Given that React is already heavily invested in Flow types, there would be _some_ form of rewrite. And like I said, Flow is providing sufficient benefit for the React team right now, and their focus is on expanding React's capabilities. Changing type systems is not on their radar as far as I know.
LaGrange 8y ago
Facebook (excuse me, bunch of FB employees from the Flow team) says no: https://github.com/facebook/flow/issues/7365#issuecomment-454956694 https://github.com/facebook/flow/issues/7365#issuecomment-45.... Of course, that's exactly what I'd say if I was in charge of a dying project. Edit: but, their main codebase is in Flow, and that sounds like a mess to migrate, so I wouldn't be _too_ worried. It might slow down, but I doubt it will become unmaintained anytime before Facebook gets sued out of business :-P
- kimsk112 8y ago
  I recalled when Microsoft employees and MVPs denied when Silverlight was dying. :-( I think the TypeScript momentum is too strong now.
  - LaGrange 8y ago
    I think Flow's in more direct trouble, but I wouldn't announce victory for TypeScript just yet. With wasm around the corner, things may (or may not, shrug) change significantly.
    - int_19h 8y ago
      Even with wasm, much as I'm looking forward to the Great JS Purge personally, it's not going to happen anytime soon - too much existing code and devices. JS will remain necessary on the front-end for at least another decade, and probably beyond that. So TS will still be necessary to make the pill less bitter.
sephoric 8y ago
I tried Flow and TypeScript out about half a year ago in a client project and Flow was kind of painful and difficult to use, the updates, bug fixes and new features weren't coming as often as TypeScript's were, and maybe 70% of people I talked to were using TypeScript instead of Flow. Since then it's more like 90% now, and the TS team seems to be adding and announcing features faster than before, whereas I haven't heard about any new features in Flow. Maybe they're there, I'm just saying I haven't heard about them. This is all anecdotal but from what I've heard, it's very common. This is a big reason I chose TypeScript in Autumn. Also, VS Code has become the de facto free editor of JavaScript projects with a full set of professional-grade IDE features across the board, and VS Code has first-class support for TypeScript but only plugin-level support for Flow. Since Monaco is simply extracted from VS Code, that means I got all VS Code's IDE features for free when I embedded Monaco into Autumn, all I had to do was set the language to "typescript" and it just works. All these free and serious benefits of TypeScript's ecosystem kind of point to this conclusion that I've seen on HN and elsewhere over and over, that TypeScript has already won and Flow is on its way out.
mrspeaker 8y ago
Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that... is there anything else on the horizon? [Edit: Nevermind: I went looking for the github issue about adding types as comments, and it turns out it's already supported by flow: https://flow.org/en/docs/types/comments/ https://flow.org/en/docs/types/comments/ - is there anything like this for TypeScript?]
- _hardwaregeek 8y ago
  TypeScript works with JSDoc annotations: https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...
  - sephoric 8y ago
    Can confirm, have sometimes added /* * @type Foo */ above a type and VS Code assumed that type was Foo everywhere else in my project, as if I typed `foo: Foo` directly. Didn't even have TypeScript in the project itself, purely an IDE feature. Extremely well thought out and useful ecosystem.
  - deleted 8y ago
    [deleted]
- Vinnl 8y ago
  Yes, TypeScript can do type checking on regular Javascript (annotated with comments) as well: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j...
- lmm 8y ago
  If you're using Babel for compatibility with particular browsers then that can already handle TypeScript. What distinction are you drawing between a compile step that "strips away the type annotations" and one that does something else - what else is it that you consider compiling TypeScript to include? I have to ask what you're trying to achieve here. Moving types into comments just gives people who build without your typechecker the chance to break your code.
jinder 8y ago
Both yarn and jest have announced they're switching to TypeScript. A corporate like Facebook would never allow that unless there was an internal shift in direction. I'd consider flow dead.
- bouncing 8y ago
  > A corporate like Facebook would never allow that unless there was an internal shift in direction. Sure they would. Flow has nothing to do with Facebook's business strategy, or its marketing campaigns, or even its corporate strategy. I'd be surprised if anyone on VP or higher even knows what it is. Insofar as "NIH" wins at big companies, it's when there's a business motive to promote a certain technology or FUD about what other technologies might exist. But engineering team A deciding not to use engineering team B's tools despite working at the same company? Happens all the time.
  - venturin 8y ago
    Engineering VPs very much know about it.
ng12 8y ago
Flow really shines when you have a large, untyped codebase and want to incrementally add types to it. If you're starting a new project (or rewriting one) TypeScript is the more sensible choice. By nature Flow is going to be used less and less over time.
- noir_lord 8y ago
  For people now thinking well we have a large untyped codebase..damn. You can turn typescripts type inference on on a regular js file. https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j...
agentultra 8y ago
I'm curious as to this trend as well. I've read the justifications for it in each case and in this particular one I don't get it. Isn't Flow more concerned with soundness than intellisense? Has TypeScript caught up with Flow in this regard? Perhaps it's because I prefer to do my work in strongly typed, pure FP languages where I can but I work professionally with JS and have been investing in Flow there for over a year now. While Flow is still not exactly great it can at least mimic exhaustive pattern matching and catches most unsafe type errors without getting in the way of common JS patterns too much. The reason the yarn maintainers are giving is because they want more contributors? What advantage will that have if TypeScript isn't catching the errors you used to be able to catch or don't know about yet? Curious to know if it's worth migrating over to TS without sacrificing anything other than the minor inconvenience.
- nicoburns 8y ago
  > Has TypeScript caught up with flow in this regard I think the answer is: it's very close. It's still a little behind flow on soundness, but it's now close enough (if you enable strict mode, which you should!) that you're unlikely to notice the difference. The TS type system is very impressive. It can't do everything that the functional languages can do, but it can do some things that they can't, and importantly it's still improving rapidly. You may be interested in the roadmap/changelog page: https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap
whatever_dude 8y ago
The writing has been on the wall for a very [1] very [2] long [3] time. Facebook and some consumers of their ecosystem have been holding the fort, but it was inevitable something like this would happen. 1: https://npm-stat.com/charts.html?package=babel-core&package=typescript&package=flow-bin&from=2015-01-01 https://npm-stat.com/charts.html?package=babel-core&package=... 2: https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F0n50hxv,facebook%20flow%20%2B%20flow%20language%20%2B%20flowtype,%2Fm%2F0hjc5m0,%2Fm%2F03yb8hb,%2Fm%2F0h52xr1 https://trends.google.com/trends/explore?date=today%205-y&q=... 3: https://developers.slashdot.org/story/18/11/25/017227/microsofts-typescript-dominates-in-state-of-javascript-2018-report https://developers.slashdot.org/story/18/11/25/017227/micros...
bluepnume 8y ago
I maintain PayPal's cross domain suite of libraries [0] and I'm fully intending to drop Flow for TS. The single thing I'm waiting for is https://github.com/Microsoft/TypeScript/issues/21699 https://github.com/Microsoft/TypeScript/issues/21699 since we use a fair amount of custom jsx rendering [1]. That's the one main thing (for me) that Flow is way stronger at right now. [0]: https://medium.com/@bluepnume/introducing-paypals-open-source-cross-domain-javascript-suite-95f991b2731d https://medium.com/@bluepnume/introducing-paypals-open-sourc... [1]: https://medium.com/@bluepnume/jsx-is-a-stellar-invention-even-with-react-out-of-the-picture-c597187134b7 https://medium.com/@bluepnume/jsx-is-a-stellar-invention-eve...

Aeolun 8y ago

I’m glad that Yarn will continue. Npm has improved, but it’s still less pleasant to work with than yarn (which basically always does what I expect, not so for npm).

h1d 8y ago
Which part of npm acts unexpectedly?
- coding123 8y ago
  We switched around June last year to yarn because git URL dependencies on branches was broken in npm. It would choose incorrect commit ids inexplicably. Beyond that dependency upgrade time is faster.
- dhritzkiv 8y ago
  Not that this is a showstopper, but I have issues with the package-lock.json file where the `resolved` field (the package's registry URL) constantly flip flops between http and https protocols, depending on which machine I'm on (home, work, or docker container), whenever I run `npm install`. Sounds not so bad, but it becomes a mess in git, and causes any docker build caches to become invalidated.
  - scrollaway 8y ago
    That sounds pretty bad and I'm not so sure it's a npm bug. Do you have a diff of the change in question? Is it on the npm registry or a custom one?
    - dhritzkiv 8y ago
      It's on the npm registry, affecting the npm client: https://npm.community/t/some-packages-have-dist-tarball-as-http-and-not-https/285/51 https://npm.community/t/some-packages-have-dist-tarball-as-h...
  - jwalton 8y ago

deleted 8y ago

[deleted]

CGamesPlay 8y ago

> The log system will be overhauled - one thing in particular we'll take from Typescript are diagnostic error codes. Each error, warning, and sometimes notice will be given a unique code that will be documented - with explanations to help you understand how to unblock yourself. Why do programmers love error codes? As an end user, they are useless indirection to me and the only way this would even be tolerable is if the explanation was printed directly next to the error code, so why bother? Is it code quality, since you don't have to write a long error message when you emit a similar error? But doesn't that have the drawback of encouraging error code reuse when it might not be appropriate? [append] Thanks for the replies! I guess I could understand error codes for search ability that also provide information about the problem specifics. Counterexample: $ yarn add foo Error YARN1001: Incompatible peerDependencies. $ yarn explain YARN1001 # Some longer text about how two of my modules have # incompatible peerDependencies Better example: $ yarn add foo Error Yarn1001: Incompatible peerDependencies. * my-package@1.0.0 |-* foo@1.0.0 |-* bar@1.0.0 |-* left-pad@1.0.1 (peerDependency of bar@1.0.0) |-* left-pad@0.9.0 (peerDependency of foo@1.0.0) $ yarn explain YARN1001 # Some longer text about how two of my modules have # incompatible peerDependencies

lost_my_pwd 8y ago
Humans are not always the consumer of error output. Distinct error codes simplify parsing and eliminate ambiguity. It also makes it easier for developers look up a specific error in the documentation, assuming it's been documented.
- dmix 8y ago
  It's also easier for a (technical) user to reference they got error 1018 than copy & paste "An index signature parameter cannot have an accessibility modifier." Especially in titles and when referencing it multiple times within a body of text.
- talltimtom 8y ago
  How does an error code make it easier to look up an error? The workflow is either “get error, google it”, or “get errorcode google it”. In both cases the docs will be the top hit. If we where talking 20 years ago I might agree, but I really can’t see the argument with todays tooling.

jcolella 8y ago

The addition of vulnerability scanning was the only reason our company switched back to npm from yarn. Other than that, yarn offers a great experience

symlinkk 8y ago
Yarn has this too (although it uses the NPM audit database): `yarn audit`.
- coolreader18 8y ago
  Oh, I didn't know that! Here's some resources about it if you haven't heard of it either: documentation; https://yarnpkg.com/lang/en/docs/cli/audit/ https://yarnpkg.com/lang/en/docs/cli/audit/ original feature issue: https://github.com/yarnpkg/yarn/issues/5808 https://github.com/yarnpkg/yarn/issues/5808 release comment in that issue: https://github.com/yarnpkg/yarn/issues/5808#issuecomment-441989817 https://github.com/yarnpkg/yarn/issues/5808#issuecomment-441...

mydpy 8y ago

For the uninitiated / confused, this refers to yarnpkg, the JavaScript dependency manager, not (Hadoop) YARN, the cluster manager.

draw_down 8y ago

At this point I don’t see how it’s clearly better than npm, and having two tools is not great.

scrollaway 8y ago

Very happy to see yarn.lock will finally be a proper format that won't need its own parser. YAML subset is a pretty good choice, though I think canonicalized, indented JSON would be a better choice for this use case. Incidentally that's what npm uses as lockfile, I wonder if there's room to have the two package managers share the format (or even share the file itself). Very excited to see shell compatibility guarantee in scripts as well. Using environment variables in scripts is a pain right now. Finally one of the biggest news is the switch from Flow to Typescript. I think it's now clear that Facebook is admitting defeat with Flow; it brought a lot of good in the scene but Typescript is a lot more popular and gets overall much better support. Uniting the JS ecosystem around Typescript will be such a big deal.

aylmao 8y ago
> I think it's now clear that Facebook is admitting defeat with Flow. It sounds to me more like they're testing the waters. They're definitely opening up, with the whole Jest and create-react-app supporting it, but as far as using it themselves would this be the first project to be migrated?
- basil-rash 8y ago
  Jest is migrating to typescript: https://github.com/facebook/jest/pull/7554#issuecomment-454358729 https://github.com/facebook/jest/pull/7554#issuecomment-4543...
  - aylmao 8y ago
    Oh, gotcha! Missed that comment.
- scrollaway 8y ago
  Jest is getting migrated to Typescript as well, not just adding support for it. And then there's... whatever this is: https://twitter.com/jamiebuilds/status/1064649666275340288?lang=en https://twitter.com/jamiebuilds/status/1064649666275340288?l...

talkingtab 8y ago

I'm curious as to why yarn instead of contributing to NPM? I am aware that yarn was the inspiration for many improvements for NPM by providing an alternative, but going forward do we need two systems? Is the plan for yarn to be compatible with NPM and package.json?

spricket 8y ago
From what I've heard, the Yarn codebase is much cleaner than NPM. If anything, I think it would make more sense to migrate NPM over to yarn
acemarke 8y ago
Yes, having competition here has clearly benefited the ecosystem. I wrote a recent comment comparing the history and goals of Yarn and NPM: https://news.ycombinator.com/item?id=18950012 https://news.ycombinator.com/item?id=18950012
whatever_dude 8y ago
I've been using both for a while and I'm happy with their decision not to try and be "compatible" with NPM. I'm also pretty happy with using Yarn only - things are just faster and in reality make a little bit more sense.

yaseer 8y ago

The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winning' has been fast, and to everyone's benefit.

ianwalter 8y ago
Maybe it's a benefit when moving from Flow, but personally, I would rather have JS projects spend that time adding more tests than converting to static typing. Edit: changed strong to static.
- janpot 8y ago
  sounds like their primary goal is 'attract more contributions' rather than 'strengthen the type system'.
- jakelazaroff 8y ago
  Static types are a form of test!
  - lucisferre 8y ago
    They are a compile time contract at best, they are nothing like a test.
    - mort96 8y ago
      A lot of tests end up testing things which would've been caught by the type system. Static and strong typing doesn't make tests in general unnecessary, but it does mean you don't need quite so many trivial tests.
    - azangru 8y ago
      They are checking the shape of inputs and outputs, making it unnecessary to test that a function returns a value of a particular type or that this value has particular fields. They make sure you don't make stupid mistakes, leaving it up to you to test really valuable bits of logic.

juancampa 8y ago

If package.json is already in JSON format, why not use the same for yarn.lock? Honest question, there must be a good reason.

arcatek 8y ago
We want the lockfile to be easy to review by humans. In our experience, JSON doesn't quite fit the bill once you reach a critical mass of data. Our lockfile format worked fine for the past three years (bar the unfortunate YAML incompatibilities that we're about to fix). Don't fix what isn't broken :)
slobotron 8y ago
Too bad it's not package.yaml or package.js so that we can include comments and document our dependencies....

misiti3780 8y ago

> The codebase will be ported from Flow to TypeScript. To understand the rational please continue reading, but a quick summary is that we hope this will help our community ramp up on Yarn, and will help you build awesome new features on top of it. Another major project moving from flow to typescript

tonyhb 8y ago
This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues. I'm a little disappointed and feel as though, similar with Kube vs Swarmkit, the worse technology is winning.
- Normal_gaussian 8y ago
  This is certainly how I feel; there are large parts of my codebases that I don't think will convert well if I was to change, where we leveraged flow to great effect. However I certainly take the point that flow has been developer hostile. When we have had issues it has been impossible to get a response (here is a demo, is this a bug or in the pipeline?). Though flow is v0.91 and Typescript is 3.2, i don't know if i can really fault them that much? I don't trust TS, they are too much 'move fast and break things'.
  - WorldMaker 8y ago
    Typescript has been moving fast, but they haven't broken that many things. The API and Language Server have changed obviously four times from a semver perspective, but in general the language itself has been extremely stable with great backwards compatibility, and most of the type system strictness additions are behind opt-in flags making upgrades usually as gentle as you prefer them to be (depending on your attitude to strict type checking). (I had projects that started with TS < 1.0 and they all still parse and compile today, albeit with tons of lint warnings, particularly to use a better module system than AMD with pre-ES2015 TS imports, and all sorts of new type strictness options to turn on to make them all the more type safe.)
- 8y ago

misiti3780 8y ago

serious question, if you are starting a new project today why would you choose to use npm over yarn?

azangru 8y ago
Because npm is a standard (default) package management tool that comes with node. After getting `package-lock.json` and `npm ci`, I would rather wonder why choose yarn instead of npm.
- MehdiHK 8y ago
  "npm ci" deletes node_modules directory every time. Try using that when you depend on some native modules. :(
  - azangru 8y ago
    I thought `npm ci` is more suited for ci machines, where it's crucial that packages are pinned to specific versions. For local development, I just npm install. Perhaps with no-save option in order to avoid updating package-lock. Works fine.
- eknkc 8y ago
  Because I don’t trust it. Had to do rm -rf node_modules too many times with npm.
ariabuckles 8y ago
Because it comes standard with most node distributions and is pretty good. It coming standard means one fewer dependency for everyone on the team to install, which is important on my current team where roughly half are backend- or mobile-only. I like both yarn and npm, and yarn would have some benefits for us, but probably not enough to counter the extra effort onboarding other devs. npm still has some pain points, but I’ve ran into a few pain points on yarn too. And I think there being multiple projects here has helped the ecosystem. npm is also doing some neat feature development (npm audit). Also, the npm team is fantastic, whereas when I adopted yarn early on they dismissed the issue I opened about yarn not working for my setup. They’re a good team, but that lowered my confidence that I’d be able to get through any obstacles while using it. It’s still a fantastic tool though.)

towaway1138 8y ago

Yarn has over 1500 open bugs. Rather than working on changes, it'd be nice to stop and address these.

arcatek 8y ago
Most of those have been fixed a long time ago, but we simply don't have the resources to triage them. This effort we start is in no small part to decrease the number of issues that will be created by empowering the users to unblock themselves* and solidifying Yarn's codebase. * You wouldn't believe the number of issues that are simply about things working as they should - we can't really blame their authors because it can be quite hard to find the right paragraph in the documentation, but it's extremely taxing on a small team. Similarly, we often have issues created against older releases, or without reproducible test case.
- towaway1138 8y ago
  I noticed the issue count while using yarn for the first time yesterday. It encountered a fatal error (Disk Quota Exceeded) and then proceeded blithely on. It's only one data point, but doesn't inspire confidence.
moogly 8y ago
And npm had 2166 at the time they archived their old GitHub repo, moved over to npm-cli (with issues disabled), and have all their issues in a Discourse forum, so you can't get an overall count, nor any connection to PRs and commits. So I'm not sure you can glean too much from just looking at an issue count in isolation.

mderazon 8y ago

> Writing posix command lines inside your scripts field will work regardless of the underlying operating system That is very nice. No need to install other dependencies just to do 'rm -rf'

arcatek 8y ago
Note that this is mostly about the command line syntax, not so much the commands themselves which will be executed just like now. That being said, maybe we'll offer some builtin as well (possibly in a similar way to what CMake offers?[1]). That would be worth an RFC later on :) [1] https://cmake.org/cmake/help/v3.2/manual/cmake.1.html#command-line-tool-mode https://cmake.org/cmake/help/v3.2/manual/cmake.1.html#comman...

jclay 8y ago

Since it seems the devs are here answering questions: Which lightweight shell will be used on Windows? Does it also bundle standard unix tools (if a script pipes to grep or less for example)? How will paths be translated on Windows? I’ve attempted something similar recently and had to do a fair amount of regex magic + using cygwins built in path translation utility to preprocess commands. Curious to see if there’s a better way to solve that.

arcatek 8y ago
> Which lightweight shell will be used on Windows? Does it also bundle standard unix tools (if a script pipes to grep or less for example)? It will be in-house, and very basic. We don't intend to rewrite bash, just to provide the basic experience that is usually needed when adding script into the `scripts` field. For more complex needs we'll simply offer a way to opt-out and use the native shell, or to call Node scripts. > How will paths be translated on Windows? The current Yarn tries to do this by using the `path` native module. It's quite error-prone since backslashes tend to appear in the worst possible places. For the v2 I plan to work with all paths in a posix style, and convert them into Windows paths right before they reach the filesystem (which is similar to what Cygwin does, as you mentioned). It would be a bit slower on Windows, but massively simpler in the codebase.
- exogen 8y ago
  I'm assuming that lifecycle scripts (and scripts called by lifecycle scripts) in particular will still need to use common Windows-supported syntax? Even if the devs of the package are guaranteed to be using Yarn, people installing the package might still be using npm. So I assume some caveats apply to some scripts, right? p.s. I love Yarn :)
  - arcatek 8y ago
    The `postinstall` scripts would likely be better off without using those features, indeed. But in the end, your packages would be better off without `postinstall` scripts anyway ;)

symlinkk 8y ago

I've got to say I'm not a big fan of some of these changes and I think they're biting off more than they can chew. > Writing posix command lines inside your scripts field will work regardless of the underlying operating system. This is because Berry will ship with a portable posix-like light shell that'll be used by default. > Scripts will be able to put their arguments anywhere in the command-line (and repeat them if needed) using $@. Similarly, scripts will have access to $1, $2, etc. If you use either of these features your package.json will no longer work with NPM. Maybe they should call it yarn-package.json? > Starting from Berry, we made it an explicit goal that each component of our pipeline can be switched to adapt to different install targets. In a way, Yarn will now be a package manager platform as much as a package manager. If you're interested into implementing PHP, Python, Ruby package installers without ever leaving Yarn, please open an issue and we'll help you get started! Noooo, god no. Package management is a gargantuan, complicated task, and these languages all have their own solutions already. That being said, it's cool that they're rewriting it in TypeScript.

maw 8y ago
I don't see the need for PHP, because composer is one of the few things I like about it. And I don't know enough about Ruby to have an opinion there. But something for Python that actually works? Yes, please!
- nhanb 8y ago
  For python we've been using poetry[1] at work. Dep resolution is a bit slow but otherwise it works well enough, definitely a saner choice than pulling in a completely different stack just for one tool. [1]: https://poetry.eustace.io/ https://poetry.eustace.io/
arcatek 8y ago
> If you use either of these features your package.json will no longer work with NPM. Yes and no. In the case of the `postinstall` script (which might indeed have to run on npm setups) you might want to refrain using those features. In any other case you simply won't use npm if you use them, because those are local scripts that only you and your team will use - and regardless of those features you should all use the same package manager anyway. > Noooo, god no. Package management is a gargantuan, complicated task, and these languages all have their own solutions already. We won't spend much time on it ourselves - as you mentioned other solutions exist and we have to pick our fights. Still, I believe this is a necessary move if we want to make our codebase clear and easy to contribute to. It's not so much about Yarn supporting everything than it is about making sure that we don't end up with a monolithic system hard to maintain.

spullara 8y ago

If you use the yarn cli and have tried the npm cli recently, why do you still use yarn? Are there big gaps that you find that NPM has failed to close?

exogen 8y ago
Unfortunately npm is probably the biggest source of my daily development frustrations, even on the latest version. I still come across bugs (that are definitely in npm itself) that have been around absolutely forever, like: > npm ERR! cb() never called! It sometimes gets its primary purpose, dependency resolution, wrong. I'll give it a perfectly reasonable package.json to install, which it will do, and then `npm ls` will still error with "missing dependency!" in some package. This should not be possible. Related, it will put packages from the flattened tree in the wrong place. I can have a dependency (that other dependencies need, specified in their peerDependencies) specified in my top-level package.json and bafflingly, npm will still move it from top-level node_modules into the node_modules of something else that happens to use it, breaking the peerDependencies I was trying to satisfy. On the install process: even if the total time to install is roughly on par with Yarn, I find that Yarn is much smoother. Whatever they're doing, they're yielding the CPU a lot more, and the result is I can actually work while it installs. npm meanwhile doesn't yield much during install and slows the whole system to a crawl. Some npm commands are extremely neglected. The "success" message printed by one of the user/permissions related commands is simply: {} Lastly, I will leave this terrifying comment here: https://github.com/npm/npm/issues/16528#issuecomment-307540010 https://github.com/npm/npm/issues/16528#issuecomment-3075400... – note this comment was left 2–3 years after receiving $10M in funding. I don't blame them for being one-upped by Yarn at every turn, but they still fail to get the basics right, let alone innovate on things.
coolreader18 8y ago
Kind of ridiculous, but yarn's CLI just feels better. It's a bit simpler, `install` doesn't really seem like an "add to package manifest" command word, there's the `global` subcommand for managing global command-line tools vs `-g`/`--global`, and no command aliases, which I like more for some reason. For me it's mostly personal preference; ergonomics would be the key difference for me. Plus, the upcoming stuff mentioned in this issue has got me excited! Edit: also, in my experience using npm for some little stuff recently, yarn is still faster installing packages. Edit2: I also like the ability to run scripts/commands from the base level of command, e.g. `yarn start`, `yarn webpack --mode production`, `yarn build:web`