https://netsuiteprofessionals.com logo
Join Slack
Powered by
Any idea why JSDoc causes unresolved functions in ...
# suitescript
c
Any idea why JSDoc causes unresolved functions in WebStorm?
e
It's been broken for me since WS 2023.5. If you remove the 
{nlobjRecord}
from the jsdoc, it should work. Sucks though, since I actually use jsdoc to build documentation.
c
to be fair, that type is wrong anyway because this is 2.1 code.
Copy code
* @param {} newRecord - The record on which to set the subtotal for each line.
This fixes the issue though
e
I've tried everything.
c
I can't commit that to codebase though, doesn't pass the standard
I wonder if Oracle care enough to fix this 🙂
e
It's webstorm, there are reports of it with other libraries. I guess one thing I never did try is reaching out to JetBrains
s
Switching to TS and no longer relying on code comments as a type system is a solution. I never run into issues like this.
c
@Shawn Talbert it would be easier to move to a different IDE
Unless you can persuade the enterprise arch team to agree to use TS.. (hint: you cannot)
s
ok, feel free to do that. I have never been keen on the idea that types are driven by code comments - talk about brittle - which you highlighted because the type in comments wasn't correct? 🙂
c
Zero chance I'm leaving Jetbrains
💯 1
s
have you tried using TS to typecheck your JS? I haven't used that much but it's supposed to be able to help even with plain JS files.
c
Is there a resource you can link to?
If it involves the team seeing TS hit the codebase then don't bother
s
I know there's an 
allowJS
config setting, but I'm sure there's multiple blogs out there or check the official TS site for more info.
Also, WS 2024.1 just introduced some sort of improved TS support - maybe try that to see if it provides useful completions for JS files too?
c
I can somehow use TS but not the rest of the team?
s
I'm referring to this setting:
'use types from server'
You can certainly experiment with it - your code would all stay 
.js
but use TS for type checking/completion only (no transpiling)
c
I think I don't understand what 'use TS' means.
outside of actually writing ts
s
c
I'm going to have to assign several hours of calendar time to investigation because I don't have a clue
I would prefer the team move to TS but the answer is no
we have very strict tooling and workflow requirements that we all have to follow
If I could use it on my side, without anyone knowing, and without it being obvious when I screenshare; I'll deep dive into it.
s
the AI overlords say something like this:
Sure, here are some articles that describe how to use TypeScript to type check a project containing only JavaScript files: 1. TypeScript: Documentation - Type Checking JavaScript Files: This is the official TypeScript documentation on type checking JavaScript files. It explains how checking works in .js files compared to .ts files1. 2. Type Checking Javascript Files Using Typescript | Brandon Rozek: This blog post provides a simple way to type check JavaScript files using TypeScript without having to set up an entire project or adjust the code2. 3. Using TypeScript to Check Your JavaScript Code: This article explains how to add a tsconfig.json file and turn on checking for all files or only some files3. 4. Type Checking JavaScript Files · TypeScript: This page from the TypeScript handbook explains how TypeScript 2.3 and later support type-checking and reporting errors in .js files with --checkJs4. 5. Is there a way to run TSC to do type-checking only for a … - Reddit: This Reddit thread discusses how to run TSC for type checking only for a single file5.
c
@ehcanadian I'll link you to my WebStorm ticket - I'm going to report the issue to them.
👍 2
s
interesting that it found a jetbrains blog article on it 🙂
c
I'm not sure this will fix the actual issue though
JSDoc killing the resolution of functions
Unless TS will ignore the JSDoc in the UI somehow.
s
Yeah, for us we're kinda the opposite - we write all our code in TS and forbid types in JSDocs
c
Different clients have different demands
For this one, we can't use TS because "the devs don't know OOP".. no further discussion allowed
s
hmm, do the devs know FP?
I sympathize though - a statement like 'the devs don't know OOP' in the context of justifying Javascript (an OOP language) is sad.
💯 1
c
That would constitute further discussion... which is not allowed 😄
They don't know FP either, they do know a lot about implementing utility functions that already exist in libraries such a lodash though
🤭 1
because we can't have something that wasn;t invented here
s
that is so horrible. I've ranted on this plenty before. You clearly have more tolerance for such things than I! I'm curious if you get TS to provide some benefit with your pure JS project - let us know.
v
If you link your jetbrains ticket I'll add to it. This has been driving me crazy. Might spend a few hours this evening trying to get to the bottom of it
a
I’m very very happy for them not knowing OOP and not accepting it for NetSuite… OOP is an over engineered paradigm so specific that I doubt many engineers ever need it on their entire career. Don’t get me wrong, I’m just old… NodeJS is another over engineered thing not needed most of the time for a simple request/response design(such as webpages, specially considering we already have PHP and JS).
s
I'm likely even older, but fail to see how JS isn't an 'OOP' language.
a
That falls into what is OOP and all the different definitions floating around. If prototypal inheritance is OOP then JS is OOP.
If you believe OOP must have class-based inheritance, then JavaScript is not OOP.
The point with my previous comment is that I'm yet to see a project/script in NetSuite with a complexity that will even remotely justify using OOP. Functional programming is more than enough for the complexity of the NetSuite problems you will be solving with SuiteScript.
But don't listen to me, I don't like OOP.
c
I don't see the harm in some OOP in SuiteScript e.g. NFT library. It seems reasonable to abstract some records into classes and use those as shared modules.
Outside of that, functional is a fine fit for the actual business logic.
s
I agree with both of you. JS is actually rather nice in that we can leverage OO and FP concepts as best fit
20 years ago I would never have thought myself ever saying 'JS is rather nice' heh.
3 Views
Open in Slack
PreviousNext
Powered by