71–80 of 104 posts
Earlier quoted context omitted.
That's a feature, not a bug. It lets A rely on version 0.9 of X while B relies on version 0.8.
I don't call that a feature. There's other ways of doing version pinning without junking up my filesystem.
Earlier quoted context omitted.
Actually, I was thinking, what's up node? Each dependency keeps a private copy of its dependencies? How messed up is that? Or am I just reading that wrong?
That's a feature, not a bug. It lets A rely on version 0.9 of X while B relies on version 0.8.
"This temporary fork enables Node.js to optionally use the Chakra JavaScript engine on Windows 10, allowing Node.js to run on Windows on ARM." (the submission title has been updated after I posted this, was initially "MS releases a fork of Node that uses the Chakra JavaScript engine instead of V8") Looks like they intend to merge back with node mainline... ? EDIT: Found this: http://blogs.windows.com/buildingapps/201…
I worked on that 4 years ago :) " rel="nofollow">http://zpao.com/posts/about-that-hybrid-v8monkey-engine/>. The Node community at the time wasn't a huge fan, though it's effectively the same thing that MS just did (build a minimal V8 API shim on top of another JS engine). I guess everybody is ok with a little fragmentation now. Our intention was also to try to get this upstreamed, however with low interest and other things to do, we didn't follow through.
I'm excited to see this, and especially to have the MS folks involved with the TC. I'd love to see an engine-agnostic API but realistically I don't think it'll happen, at least not anytime soon. Right now Node itself definitely relies pretty heavily on the V8 APIs. Those APIs can be abstracted for the most part (even if each engine is just shimming those parts of the V8 API) but the other problem is the longer tail of binary npm modules. Right now they have the full V8 API to work with. If they do a shim layer then it will come at cost for every vendor except V8. And then maintaining that layer as V8 changes APIs. If you go the engine-agnostic API route, then you will need coordination between engine vendors. That opens the doors to a multitude of problems.
Earlier quoted context omitted.
Meanwhile it's also a "who cares?" problem for the npm people. They don't use this OS, and don't expect ever to do so. I think the node_modules directory structure is a novel, though straightforward, solution to the problem of interdependent module versioning. It's very Unix; it reminds me a bit of GNU stow. It makes perfect sense that it will be tweaked in the new npm to be less redundant, but it only really makes s…
It doesn't even seem like an obvious solution to the problem. Take Maven for instance: a global dependency repository under which the dependencies are stored in the form / / . If X depends on Y.1 and Z depends on Y.2, so what? You have all the dependencies stored on your filesystem in a relatively flat structure.
"All direct dependencies are in the node_modules directory, full-stop" is a pretty simple rule. Really, that's the only rule, and that's all of it. You don't need to worry about second-order dependencies, because those are direct dependencies of some other module, which means... they are in that module's node_modules directory.
"This temporary fork enables Node.js to optionally use the Chakra JavaScript engine on Windows 10, allowing Node.js to run on Windows on ARM." (the submission title has been updated after I posted this, was initially "MS releases a fork of Node that uses the Chakra JavaScript engine instead of V8") Looks like they intend to merge back with node mainline... ? EDIT: Found this: http://blogs.windows.com/buildingapps/201…
Earlier quoted context omitted.
Given all that Microsoft has been doing lately I'd really be surprised if this is all an elaborate ruse to squash node. Having been around when the actual "embrace, extend, extinguish" was running at full throttle, though, I can tell you what it does looks like: "Full access to UWP APIs from Node.js applications" When you use platform-exclusive features then you not only lose a major strength of node, but you put the…
It's a choice for the developers. They can use Node standalone or inside a Universal Windows application with access to the underlying platform using JavaScript.
"This temporary fork enables Node.js to optionally use the Chakra JavaScript engine on Windows 10, allowing Node.js to run on Windows on ARM." (the submission title has been updated after I posted this, was initially "MS releases a fork of Node that uses the Chakra JavaScript engine instead of V8") Looks like they intend to merge back with node mainline... ? EDIT: Found this: http://blogs.windows.com/buildingapps/201…
> Might lead to a SpiderMonkey version of Node.js at some point, too. I worked on that 4 years ago :) " rel="nofollow">http://zpao.com/posts/about-that-hybrid-v8monkey-engine/> . The Node community at the time wasn't a huge fan, though it's effectively the same thing that MS just did (build a minimal V8 API shim on top of another JS engine). I guess everybody is ok with a little fragmentation now. Our intention was a…
I'm not sure exactly where I sit on this one. In many regards I think I like it, allowing developers to use the right engine for the right job, for example. Each engine has its own strengths and it may be that v8 isn't the engine for you / your workload. It's just this could hurt as much as it helps.
Earlier quoted context omitted.
That's a feature, not a bug. It lets A rely on version 0.9 of X while B relies on version 0.8.
Unless you create file paths that are so long that they break the default tools of the OS. That’s the point where you went too far.
I know Microsoft apparently has changed, but just to play devil's advocate: [x] embrace [x] extend [ ] extinguish