-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Make native
non-enumerable
#1992
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
41c411a
to
32ba854
Compare
Test failures are from tests that are flaky on master. |
lib/index.js
Outdated
throw err | ||
var native | ||
Object.defineProperty(module.exports, 'native', { | ||
enumerable: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of a get
here implies writable: false
, and Object.defineProperty
defaults to configurable: false
. Any of those could be breaking changes, depending on how clients are interactive with native
(are they overwriting it?).
Cloning or iterating over |
Unintentional cloning is pretty common in ORMs like Sequelize where models have a reference to DB connections. So making a deep copy of a model instance ends up enumerating But cloning a I think a more likely use case that this PR could break is consumers overriding or deleting |
Can we have this merged and released ASAP, please? In sequelize, there are weird errors |
@1valdis That’s probably a bug you or Sequelize should fix, not hide. Deep-cloning clients is a bad idea. |
Any chance this will get merged? |
yah we try to be as pedantic as possible about breaking changes and this is technically a non-backwards compatible change. I agree it's super bizarre to enumerate the pg instance but folks do bizarre things sometimes. It's also a small thing, but i'd like to see at least a simple unit test that does something like
or something just to future-proof against this changing. I also totally agree w/ charmander...if code is 'randomly' throwing an error about pg-native not being installed it's nothing to do w/ this module directly (though making the prop non-enumerable will probably help those situations) because pg doesn't do anything randomly wrt requring native so it's the consuming module's responsibility to fix that random error, not here. |
@brianc Does that mean this PR should be reworked to be backwards compatible, or that you're fine releasing a new major version of node-pg? I'm not sure there's an easy way to make it backwards compatible. Instead we may have to introduce something like #1894 that allows consumers to opt-in to this change. |
I think leaving this as non-backwards compatible is fine. I need to do a semver major bump soon and I'll sweep it into those changes when I do that. If things pan out well I'll be able to do it this weekend, but if not definitely in the next few weeks. Holidays + lots of travel make things extra slow...but I appreciate the work and will release it ASAP! |
Awesome news. Waiting for the release, hoping that Sequelize won't break with major version change of pg. Is there a (preliminary) list of breaking changes? |
not yet w/ the list of breaking changes but will be coming soon as soon as
I have a chance to put it together. :)
…On Wed, Nov 20, 2019 at 2:24 AM Vladyslav Huba ***@***.***> wrote:
Awesome news. Waiting for the release, hoping that Sequelize won't break
with major version change of pg. Is there a (preliminary) list of breaking
changes?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1992?email_source=notifications&email_token=AAAMHIJGX3KF6WM6XBKETOTQUTX2RA5CNFSM4JB5T6NKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEREKLA#issuecomment-555894060>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMHIOWVB3YXMFR5Q65DZTQUTX2RANCNFSM4JB5T6NA>
.
|
07f44a7
to
18a8e14
Compare
Making it non-enumerable means less spurious "Cannot find module" errors in your logs when iterating over `pg` objects. `Object.defineProperty` has been available since Node 0.12. See brianc#1894 (comment)
18a8e14
to
45a427e
Compare
Rebased to fix merge conflicts, but otherwise no changes were made. @brianc Let me know if there's anything I can help with to get this merged and released. |
Will do! I cut my fingertip off on NYE so cant really type (1 hand all
bandaged) - i expect to be back in service on Monday at the latest and will
review and merge in an 8.0 branch shortly! Wanna get 8.0 out asap so I can
start on some major refactoring for 9.0!! Thanks for the PR! ❤️
…On Fri, Jan 3, 2020 at 4:32 PM Gabe Gorelick ***@***.***> wrote:
Rebased to fix merge conflicts, but otherwise no changes were made.
@brianc <https://github.com/brianc> Let me know if there's anything I can
help with to get this merged and released.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1992?email_source=notifications&email_token=AAAMHIMGEOXFNJ7YBGEU6HLQ364GHA5CNFSM4JB5T6NKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEICHPPY#issuecomment-570718143>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMHINMYP22YUBKKI4Q7BTQ364GHANCNFSM4JB5T6NA>
.
|
Landed on the 8.0 branch with a test in #2065. |
I've just been chasing down this issue and I think in my case it is caused by TypeScript's implementation of ES module imports: __importStar = function (mod) {
if (mod && mod.__esModule) return mod;
var result = {};
if (mod != null) for (var k in mod) if (Object.hasOwnProperty.call(mod, k)) result[k] = mod[k];
result["default"] = mod;
return result;
}; My use-case is using |
Making it non-enumerable means less spurious "Cannot find module" errors in your logs when iterating over
pg
objects.Object.defineProperty
has been available since Node 0.12.See #1894 (comment)