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

Using underscore in vendor.js seems to conflict with Restangular #1209

Closed
Phocea opened this issue Sep 22, 2016 · 9 comments
Closed

Using underscore in vendor.js seems to conflict with Restangular #1209

Phocea opened this issue Sep 22, 2016 · 9 comments
Assignees
Labels
Milestone

Comments

@Phocea
Copy link
Contributor

Phocea commented Sep 22, 2016

Description

Using the 1.0.0-alpha7 version build I am getting the error _.includes is not a function when acessing any of my entity list views

Following several threads on Restangular Git (one of them being mgonto/restangular#1225). I found this is a know issue with Restangular and various changes in the underscore and lodash librabr
Restangular 1.5.2 is now using "lodash": ">=1.3.0" which fixes the issue.
However using underscore for the _ global value offuscate it to Restangular.

This issue only occur since commit cc21984 (webpack dependencies commit).
It occurs if I use the already transpiled libs, or transpile them myself using webpack. Before this, using the minified build if ng-admin-only did not cause any problem.

Changing the following line in vendor.js fixes the problem but your CI does not like it...
from:
global._ = require('underscore');
to:
global._ = require('lodash');

The error stack encountered is (ml-sp-opui.js.js is my webpacked app):

angular.js:12798 TypeError: _.includes is not a function at Object.t.isSafe (restangular.min.js:6) at Object.O (restangular.min.js:6) at Object.A (restangular.min.js:6) at e.value (RestWrapper.js:19) at t.value (ReadQueries.js:19) at Object.e.state.resolve.rawEntry (routing.js:166) at Object.invoke (angular.js:4570) at c (angular-ui-router.js:475) at angular-ui-router.js:467 at processQueue (angular.js:15112)

@jpetitcolas jpetitcolas self-assigned this Sep 26, 2016
@jpetitcolas
Copy link
Contributor

@Phocea: I can't reproduce the issue on the example app (using make run), even after a brand new npm install. Can you pinpoint the issue more precisely?

@Phocea
Copy link
Contributor Author

Phocea commented Sep 26, 2016

I will have another go and also check if the issue occur with the build under Linux.
At the moment I have got around the problem by automatically patching the vendor.js during my Maven Windows build, prior to do the webpack and test phase.
In any case, it seems that lodash is a better choice for the future than underscore (which it includes), but this is another discussion :)

@Phocea
Copy link
Contributor Author

Phocea commented Sep 26, 2016

@jpetitcolas I still have the issue both on windows and linux build and really cant see what could cause this side effect.
Best may be too close this PR since I have a valid workaround, and maybe create an enhancement with low priority to move to lodash in the future.
You could also ask @fzaninotto if he spotted any issues going to lodash rather than underscore when doing this task: #845

@beatelite
Copy link

beatelite commented Oct 21, 2016

I just ran into this same issue. The weird thing is, It works fine in my dev server. When I git clone and then npm install on my production, I get TypeError: _.includes is not a function when trying to visit any entity.

I'm on linux in both instances running v1 beta 2 of ng-admin.

@Phocea Can you walk me through how to resolve this?

@Phocea
Copy link
Contributor Author

Phocea commented Oct 21, 2016

Hello,
You can either branch the code and apply those changes #1208
What I have one is to patch the file prior to run webpack. i am simply replacing underscore by lodash in the node_modules/ng-admin/src/javascripts/vendor.js file

@Kmaschta
Copy link
Contributor

Can you confirm that the PR #1208 fixed the issue?

@Phocea
Copy link
Contributor Author

Phocea commented Nov 18, 2016

It does, we carry on patching the file inside our build for now.
We can try reopening the PR once Travis is fixed

@fzaninotto fzaninotto added this to the 1.0 milestone Nov 18, 2016
@Phocea
Copy link
Contributor Author

Phocea commented Nov 22, 2016

Re-applied changes in #1252

@Phocea
Copy link
Contributor Author

Phocea commented Dec 8, 2016

And once again reapplied in #1268

@Phocea Phocea closed this as completed Dec 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants