<@U2C4P9YR3> <@U7A0KGURX> Thanks fellas, that work...
# suitescript
j
@creece @alien4u Thanks fellas, that worked! My final version below has it working with the library in a utilities folder. First time trying lodash, hopefully i don't need much help. define(['N/record', 'N/currentRecord', 'N/search', 'N/runtime', 'N/ui/dialog', './utilities/lodash'], function (record, currentRecord, search, runtime, dialog, _) {
c
Yep, looks right. The lodash doc is pretty good and stackoverflow is littered w/ lodash questions so you'll probably be able to find anything you need between the 2 sites.
s
Is there a particular reason you are using
_
instead something explicit like
lodash
as the identifier for it?
👍 1
b
_ is easily recognized as a utility library
probably started by the underscore.js and then copycat lodash.js both using _ as their global
same thing for $ being used for html libraries, blame jQuery's $ global
r
Something related to this question, as I am also planning to use such libraries. Which one is your approach when using external libraries (example - Lodash) to integrate them in SuiteScripts? Do you keep a folder in the file cabinet only with the .js files of those libraries? And then reference them in each of your scripts. Or do you have like an "instance" of those files per SuiteScript project that you work on? (even thought it might in the same account) Do you ever update the libraries? If so, how? I believe normally people use https://www.npmjs.com/ to keep the libraries sync, but I do not know if we can achieve the same in SuiteScript (I guess specially relevant for Server Side Scripts) and whether is a good idea at all due to, for example, risks of something getting broken due to an update in the library. I am just thinking about what's the best approach for the long term
b
Shared location for library files means you never update those libraries
Or are willing to check all your code for errors when you do update
r
Not really wise, I guess. So, just have a copy of the javascript files per "project" is the way to go?
c
I make a "third-party" directory in the root of where my projects are and all projects take from that third-party folder. I've never had to update any versions of what i'm using so its worked fine for me.
so if you have your projects under SuiteScripts/Roc127 you'd make a third-party folder in there and then your projects are also under the Roc127 folder.
r
Thanks for the input @creece! I think I might follow that approach as well, as I also do not think I will update very often the util module files. At least that's what I have noticed in my experience when using my "own" utility module. And this way everything is more tidy, like only one place where you need to look for those functions. Although is also true that you lose some flexibility if you would like to update any util file that might be in use somewhere else. But if there is no way / or does not make sense to somehow use the npm package manager or something similar (that I have no experience yet with) with NetSuite, and you have to do it manually yourself, then I think the "risk" can be managed easier than if those files were being updated "automatically"