231–240 of 486 posts
Earlier quoted context omitted.
There has been no problems with folder nesting in `npm` in general since the version@3 came out over a year ago.
fwiw npm really needs an `exec` command like bundler has (ie `npm exec bin-cmd`). "$(npm bin)/bin-cmd" is getting really old
Earlier quoted context omitted.
I can't speak for either project, but personally I would say that I don't think static typing in JS is a solved problem, and at this stage to me it seems a monoculture would be much less fruitful than a competition of ideas.
I would agree if they were at all different, but they seem to be syntactically and functionally identical. As a caveat, I am a daily TS user, and have only played around with Flow.
What this means in practice I don't fully understand but it seems to result in enough architectural differences that it apparently makes sense to have both despite the superficial similarities in syntax and behaviour.
I use JS+Node+NPM for my day job and many side projects. Initial thoughts: - Why didn't Facebook contribute the updates to NPM directly? - They are coupling a package manager and registry proxy; the latter has many existing implementations already - The differenced between Yarn and NPM+Shrinkwrap do not seem substantive; NPM made the design decision to use a sometimes non-deterministic install algo in NPM3 to speed u…
IMO it's the "javascript way" to invent new tools instead of trying to improve others (when it makes sense to do so). Let me explain that a little bit... The javascript "ecosystem" takes the unix philosophy to the extreme in many ways. And one of the points of the unix philosophy is to try to avoid "bloating" tools with tons of options, and instead trying to create new tools where appropriate. Many of those are perfe…
Does yarn support custom `run` commands like npm? For example: "scripts": { "dev": "node api.js --config config-dev.json" } $ npm run dev
Yes. See the diff here for an example of moving a project from one to another: https://github.com/rust-lang/crates.io/pull/457 lots of "npm run" -> "yarn run" there.
Earlier quoted context omitted.
As I understand it, it automatically locks in the (exact) version of everything you install, rather than having this as a separate, optional feature (like shrinkwrap does, despite it not working well - but that's an implementation problem). The big deal about semver and how it's implemented in NPM is that there is a choice of how to deal with it - either you automatically allow compatible updates and risk an occasion…
> Why bother with semantic versioning if everybody is expected to manually > check and pin their dependencies anyway? I think this is the disconnect here: the lockfile does protect me from updates, but ranges are still useful: they allow a tool to help me upgrade my dependencies. With the lockfile-based approach, you usually _don't_ pin to specific versions: with Cargo, we even defaulted to the ^ operator, so 'foo =…
I understand that, but you're looking at it from a technical perspective, while it's partially a psychological issue - namely, the question of how you drive certain desirable behaviour.
When you make upgrades explicit, rather than automatically installing newer versions, you reduce the deployment of (security) bugfixes, because many people simply will not run `upgrade`.
The reason is that you've created an expectation of manually checking versions before updating them - after all, why would it be a manual action otherwise? - and people do not want to commit to doing that. That is why this will harm the ecosystem - it undermines the mutual trust that a maintainer will be using semver, and that you can rely on it to automatically get updates.
The solution is simple: make lockfiles opt-in. That doesn't mean that you can't aggressively require a developer to lock their versions once they have opted in - it just shouldn't be a feature that is enabled by default.
> But repeatable builds are a big deal, and managing dependency ranges so you can still use semver while getting repeatable builds is a big deal. Even for smaller organizations.
For many people, it really isn't. Comparing the tradeoffs of manual upgrade management vs. the chance of occasional breakage due to non-determinism, many people will pick the latter.
And I'm not just talking about "organizations" here either - there's plenty of development going on outside of any organization, on personal projects, and that is precisely the kind of development you'd want to encourage.
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 _many_ of the same problems as Facebook with our NPM setup -- long CI/CD build times, indeterminate node_modules directories that caused our projects and tools to work for some people on our team but not for others, and the inability to do "offline-only" npm installs in CI.
We actually talked with our friends at Facebook about these problems, and tried many of the same approaches they did -- shrinkwrap everything, checking in node_modules, uploading the node_modules folder to separate place (we used another completely separate Git repo), etc. All these approaches either didn't work well or were difficult to maintain, especially on a small team.
Yarn has fixed all these issues for us.
One not-yet-super-publicized feature of Yarn (though I'm told there is a blog post coming) that has been super useful at Exponent is the ability to build a distributable offline cache of dependencies. We have a "node_modules-tarballs" folder in our mono-repo that contains tarballs of all the dependencies for every single project that we maintain at Exponent. Yarn will pull from this cache first before fetching from the NPM registry. This offers HYPER-predictability...it's a level of confidence over and above the "yarn.lock" file, and let's me sleep well at night knowing that my team can get up and running quickly no matter where they're working, how reliable their internet connection is, etc. No more worrying about "did I forget to update the shrinkwrap" -- things just work.
As JS developers, we all, beginners and experts alike, can experience this "JavaScript fatigue" that we always hear about. Fighting with tools is never fun. We just want to write code!
As we've started to use Yarn at Exponent, both on our engineer's machines as well as in our continuous integration and deployment environments, we've at least had one less tool to fight with. Yarn works, works fast, uses the great parts of the NPM ecosystem that we know and love, and most importantly, is _predictable_.
Earlier quoted context omitted.
Multiple versions may sound like it's useful, but it's almost always a bad idea. Cargo doesn't allow it either. The problem isn't really fundamental. Bundler makes almost all the right choices already. Its major disadvantage is that it only works for Ruby.
> Multiple versions [...] almost always a bad idea If so, different major versions of the same dep should be considered different libraries, for the sake of flattening. Consider lodash for example.
Earlier quoted context omitted.
> Flow, introduced 3 months after TypeScript Do you think Flow was built in 3 months as a reaction to Typescript? Not that it was a big enough problem that two different groups of people independently decided to try to solve it? EDIT: disregard this, Flow was introduced much longer than 3 months after TypeScript. The blog post introducing Flow mentions TypeScript, and is probably worth reading for background [1] > Nu…
TypeScript was released October 1, 2012. Flow was released November 18, 2014 Did Flow take 2 years to get implemented? I didn't think the initial release looked like a project that had 2 years of dev time on it.
Earlier quoted context omitted.
There has been no problems with folder nesting in `npm` in general since the version@3 came out over a year ago.
It's improved but it's not fixed. if a depends on c 1.0 and b depend on c 2.0, both versions of c need to be installed and one of them will be nested.
This 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…
For browser work, you can do almost everything you need with some jQuery, handlebars and moment if there are dates. A few other small libs here and there and you've got almost everything covered. Some edge cases may drive you to use some library that is heavily dependent on 32 different sub-libs but it's really not that often.
Server-side Node.js is the issue, not browser compatibility.