interesting dilemma… custom modules don’t support ...
# suitescript
s
interesting dilemma… custom modules don’t support the @NAmdConfig JSDOC tag… so any requirements for this need to be added to the calling script, and subsequently passed to the desired custom modules. I hope I’m just doing something wrong, but my testing shows that when the tag is added only to a custom module, the calling script throws a module load error.
a
JSDoc are just comment blocks they don't really do much of anything, I'm not really understanding what your issue/concern is?
custom modules are generally used in multiple places, that's the point of making them reuseble custom modules usually. so of course they have to inherit the JSDoc stuff from the calling script, that's the only thing that's really executing
I doubt there's JSDoc tags in the various non-custom modules too, because... why would there be?
what tag do you want to include in your custom module?
scriptType makes zero sense for a module so... api version? or ModuleScope? when would you want either of those to be different from the executing script?
a
okay I knew it would have to be something weird, I've literally never used this 😄
I didn't even recognize that you were specifically referencing it in the initial post, just saw JSDOC and made assumptions.
1. what's the use case for this 2. can you leverage the following to workaround the issue you have with custom modules? require.config call?
Copy code
Important:

Configuration of a require Object is optional and for advanced users only. If you must configure a require Object, the @NAmdConfig JSDoc tag is suited for general use and is the preferred way to configure a require Object. However, existing scripts with calls to require.config() can use this method with a context argument (although not preferred). Ensure that the call includes a context parameter and that its value is not a file path.
what's in the JSON you reference? can you no just load the file itself? and then parse the JSON into an object if its just a key value store? if that's the use case, I generally handle this stuff in custom record singleton that admins can edit as needed in the UI, like a solution preferences / config /setup page I load that custom record and cache everything in it so its just readily available.
s
@Anthony OConnor The use case is building a custom module wrapper for SheetJS. SheetJS Docs for NetSuite/AMD NetSuite install docs on SheetJS: https://docs.sheetjs.com/docs/demos/cloud/netsuite/ Documented fix for AMD, requiring use of @NAmdConfig https://docs.sheetjs.com/docs/getting-started/installation/amd/ The SheetJS library, and my companion module make it simple to export to
any-array-data.xlsx
via client script or suitelet. I got it working, but it would be much more sexy if I could put the whole mess in a custom module, instead of hard-coding dependencies in the calling suiteScript.. I can show you the code if you want to check it out…
a
huh okay yeah this does seem cool, and pretty involved too 🙂 I've heard of SheetJS multiple times but never used it myself.
s
It’s pretty great man..!
I have scripts to copy Suitelet Row HTML to the clipboard to support copy/paste to excel, but this will be a better experience.
a
yeah sounds pretty neat, so is this a reuseable custom solution? or a suiteapp you're building? your consulting now right not with an end user?
s
yes, it’s a reusable library for all of our projects.
e
Yeah, this has been true for as long as I remember, and it's always a pain.
b
@suitedev Check this out, this also outputs an array to XLSX: https://ursuscode.com/netsuite-tips/convert-large-netsuite-csvs-to-xlsx/
👍🏻 1
👍 1