raynos / xtend Goto Github PK

I had an issue with mercury and tracked it down to mutable.js. I then later tried virtual-dom on it's own, and had the same problem. I realised that the error is getting thrown when I transpile my code from es6 via 6to5-loader - which prepends all wrapped modules with "use strict". My current options are:

1. don't use virtual-dom
2. don't transpile from es6
3. filter out my node-modules folder from the loader (most likely solution)

this isn't urgent, so I'd flag it as an enhancement/proposal - I'll take a look at it myself later if I get a chance.

Hey @Raynos!

I know this project is frozen, but I figured I'd reach out anyway because receiving an extra $100/month is nothing to dismiss.

Anyway, I just started at Tidelift and have been looking through our list of projects that have funding available and noticed xtend has almost $100 per month that can be claimed by you. I’d love to get you signed up so we can start paying you this money.

The high-level overview of Tidelift is that we sell a “managed open source” subscription to companies and pay that money out to maintainers. We use their dependency trees to determine which packages are depended upon and, therefore, should get the funds. You can read more about Tidelift’s subscription service on our site.

The tasks we ask you to perform are things that most maintainers already do (such as provide release notes, validate the license of a package, and monitor and alert for security vulnerabilities), but you can find the specific details in this blog post by @kszu.

Please let me know what you think! I’m happy to answer any other questions you might have. 😄

Thanks for all your open source work,
-Blaine

I'd expect xtend({foo: 1}, {foo: undefined}) returns {foo:1} but it returns {foo:undefined} is this ok?

https://github.com/ljharb/object-keys

right now, npm logs:

npm WARN deprecated [email protected]: Please update to the latest object-keys

This module should be really simple and have no dependencies. object-keys has a wonkey dependency tree.

Either drop ES3 support or inline a naive subset of the shims

Hey, I'm about to implement some recursion to do "deep-xtend". Interested in a PR for that?

Just a heads up your license file is mis-spelled 'licence' and is therefore your license isn't discovered properly by nlf (https://www.npmjs.com/package/nlf)

After merging #15, could you republish this to npm? The dependency tree will become much cleaner, and I'd like to update one of xtend's dependents to benefit from the lighter tree.

this results in license checking tools to fail. please fix. (merge !31)

It would be nice to support recursive xtend.

ES6 will be providing Map and WeakMap. We should privde the ability to return one of them instead.

What do you think about,

extend(super, override, <form>);

Where form defaults to the typeOf super?

I noticed while taking a peek at levelup, that it depends on xtend. And then noticed that xtend's objectKeys method isn't an equiv for Object.keys.

A proper polyfill is non-trivial and is actually more complex then the one referenced. However, it's up to you how much support you want to extend (no pun intended). The bare minimum would be simply adding hasOwnProperty checks.

What's the difference between this package and the core function Object.assign()?

Bloats the browser build for no reason. Leave this stuff to es5 shims.

Just a heads-up for whoever maintains this library, the new versions pushed in the last few days broke the library for me (I was foolishly pulling the tarball for the latest version every time).

Not sure why, but I think it has to do with setter methods. I use Mongoose, which uses objects that look normal, but actually have setter methods attached to each property so it can mark them modified when they change.

The simple case that broke is:

// oldObj is a Mongoose object: { inTime: 0, outTime: 3614.8 }
// its inTime/outTime have setter methods
extend(oldObj, { inTime: 0, outTime: 1934.30255 });
// oldObj.outTime is still 3614.8, it should be 1934.30255

I'm using 1.0.3 for now, which works fine. Not sure what the problem is, but thought I'd let you know!