Skip to content
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

@babel/polyfill loaded multiple times #2955

Closed
klaemo opened this issue Dec 14, 2018 · 6 comments
Closed

@babel/polyfill loaded multiple times #2955

klaemo opened this issue Dec 14, 2018 · 6 comments

Comments

@klaemo
Copy link

@klaemo klaemo commented Dec 14, 2018

Environment

Knex version: 0.16.2
Database + version: Postgres 9 + CockroachDB
OS: macOS + linux

Bug

@babel/polyfill is loaded more than once on this page. This is probably not desirable/intended and may have consequences if different versions of the polyfills are applied sequentially. If you do need to load the polyfill more than once, use @babel/polyfill/noConflict instead to bypass the warning.

This might happen because we require knex in two different files as we use two different databases. If knex is only to be required once per server/app (which would be weird), I guess that should be mentioned somewhere? Did I miss that?

I think it's not a good practice to include @babel/polyfill in a library. Like in the browser libraries shouldn't mess with the global scope. From the @babel/polyfill documentation:

This will emulate a full ES2015+ environment (no < Stage 4 proposals) and is intended to be used in an application rather than a library/tool.

@kibertoad
Copy link
Collaborator

@kibertoad kibertoad commented Dec 19, 2018

0.16.3 is out with a fix for this.

@klaemo
Copy link
Author

@klaemo klaemo commented Dec 23, 2018

Thank you!

@wubzz
Copy link
Member

@wubzz wubzz commented Jan 30, 2019

Imho it feels a bit strange to have a dependency in a project which is only used for a specific Node version.

Could we either

A) Remove the dependency and attempt a vanilla fix for Node 6? (Not sure what the fix is for, maybe it's too complex?)

B) Force the user to install the dependency the very same way we force users to install the db drivers?

CC @elhigu @kibertoad @tgriesser

@kibertoad
Copy link
Collaborator

@kibertoad kibertoad commented Jan 30, 2019

@wubzz Vanilla fix is going to be complex, e. g. we don't really want to implement Object.values by hand. I'm OK with forcing user to install the dependency, but it also means that he would need to manually require it as well. This would mean that our tests are not going to pass on Node 6. Maybe we should just drop Node 6 support already and release 0.17.0?

@wubzz
Copy link
Member

@wubzz wubzz commented Jan 30, 2019

Similarly to how dialects are handled we could just try/catch the require in linked PR and notify the user to install the dependency if it's not already installed. So user doesn't have to have their own require. (This is how dialects are required afaik)

As for our tests we could still use it if need be, as a devDependency.

This is not a big issue it just hit me when upgrading from 0.15.

@kibertoad
Copy link
Collaborator

@kibertoad kibertoad commented Jan 30, 2019

Sure, that sounds reasonable. I'll cook up a PR today if I have any spare time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants