271–280 of 486 posts
yarn global add typescript yarn link typescript error No registered module found called "typescript". info Visit http://yarnpkg.com/en/docs/cli/link for documentation about this command. what? edit: also, $ yarn add typescript yarn add v0.15.1 [1/4] Resolving packages... [2/4] Fetching packages... [3/4] Linking dependencies... error ENOENT: no such file or directory, open 'C:\Users\******REDACTED******\@types\react\i…
Earlier quoted context omitted.
You say tooling, but then talk about libraries. I think both are just as numerous for nearly all popular programming languages. It’s just that JavaScript is currently “hot shit”, so all this stuff is a lot more visible. There are tons of libraries for C, many of which aim to do the same, only faster/smaller/scalable/whatever. There are many compilers, both open and closed source. And there are documentation tools, sy…
You say tooling, but then talk about libraries. Because, from this outsider's perspective, it seems like most of the tooling is library management (rather than, say, profiling or linting -- does javascript even have a linter? -- or debugging).
There are tons of tools, of course also including jslint, debuggers (e.g. IntelliJ, dunno about others). There are editors and even IDEs. Then there’s the problem of bringing (NPM) modules to the browser using tools like webpack or SystemJS or whatever. There are general purpose build/automation systems like gulp. There are transpilers that “compile” ES6 to ES5. For any given task, you can probably find at least five programs that do it.
And if you look at all the topics, you’ll find that library management makes up only a small fraction of everything.
Earlier quoted context omitted.
You can use webpack or JSPM to resolve directories at the top level. That way you can just import "web/X" even if the web/ directory isn't a sibling to your current file. It's not very helpful if you are distributing an NPM package, but for people who aren't authoring libraries, its a godsend.
Do you mean import '/web/X'? Import URLs have to start with a `/`, `./`, or `//`. Even so, that requires a build tool. I want to be able to load working sources directly out of my packages directory.
Not if you use a build tool for your frontend.
> Even so, that requires a build tool.
That was basically what I was suggesting. I'm not sure what the other option really is. If you're working within the browser (implied by this being a frontend), then you have to use a build tool since javascript modules/imports haven't landed in any browser yet.
so, where are the packages stored? how is this more secure than npm? how does this solve the leftpad problem?
Exponent has been testing out Yarn for about a month, and it's been an incredibly pleasant experience, both in working with the Yarn team and using the tool. Exponent uses a monolithic code repository (rather than many small code repos) to manage our many interdependent projects. Our repo is actually setup very similarly to Facebook's mono-repo, though obviously considerably smaller in size. We were encountering _man…
Definitely looking forward to that blog post from the Yarn team, but I'd definitely be interested in your own comments on how to use that "checked-in tarballs" approach.
I'm really liking yarn. It solves some of my main issues with npm, it's fast and it provides some great output in the CLI. It's also architected absolutely ingeniously . Seriously they have positioned themselves to seamlessly take over npm's entire business just like that. What do I mean? So today by default yarn goes through its servers which then proxy to npm's. As time goes Facebook can add more features to its ow…
npm should not be terrified, we've been working with them and they've been very encouraging. From their perspective it's very difficult to make breaking changes to the client because of the sheer number of people depending on them. (We've faced similar problems on Babel) Yarn still makes use of the npm registry and all the high quality infrastructure they've built and support they provide for the ecosystem. They are…
Granted it's far too early to write npm off. But with how slow they've moved over the years I'm unconvinced that yarn won't take over the space unless it runs into some bad problems. Npm 3 and its launch was an absolute mess and, ultimately, it's almost just a package managing tool. I am unconvinced that breaking changes is much of an issue if at all for them. They could abandon shrinkwrap into a better system and I think everyone would be happy for it; no need to keep propping up that awful system.
I'm really liking yarn. It solves some of my main issues with npm, it's fast and it provides some great output in the CLI. It's also architected absolutely ingeniously . Seriously they have positioned themselves to seamlessly take over npm's entire business just like that. What do I mean? So today by default yarn goes through its servers which then proxy to npm's. As time goes Facebook can add more features to its ow…
As Yehuda pointed out, such a thing won't happen because Yarn was launched as a community project from the beginning, and a lot of members contribute to both, so even if Facebook decided something sketchy, the community would either stop it from happening or continue with a forked version.
Would they, though? If Yarn turns out to be the better tool that doesn't change the way they work (beyond solving some pain points) then would they even care? Facebook could even offload the hosting to some open source group like Apache.
It's purely anecdotal but a lot of people I have worked with would love to see an alternative to npm. It's just slow and the features it gives to authors is pretty limited (I want better metrics, please!). I'm not even sure I would call it sketchy, it would just simply be phasing out something deprecated (I'm not talking about a swift take over more like a slowly-boiling-the-frog-in-the-water takeover).
It's only my opinion and if Facebook really doesn't want that to happen then I guess it won't but it's pretty easy to imagine it, IMO.
Earlier quoted context omitted.
Have you guys approached the ridiculous folder nesting situation? E.g. breaking out of the current/broken node_modules structure?
There has been no problems with folder nesting in `npm` in general since the version@3 came out over a year ago.
Absolute and utter hogwash.
I don't even need to get into versioning to make this argument but I'll exclude it for clarity's sake. Simple scenario:
root -> A
root -> B
root -> C
A -> B
B -> C
root/node_modules/A/node_modules/B/node_modules/C
root/node_modules/B/node_modules/C
root/node_modules/C
NPM version@3 could not be further from the ethos of "engineering." It's an outright hack, and it quickly betrays its limitations. It could have been far simpler, far more considerate of pre-existing wisdom.
wow already one of the features i'm loving in yarn is that it tells you which package is firing warnings about package incompatability. warning electron-prebuilt-compile > electron-compilers > jade@1.11.0: Jade has been renamed to pug, please install the latest version of pug instead of jade in npm, that would have just said the part after "jade@1.11.0" which was really vague and didn't really make you want to "fix"…