https://netsuiteprofessionals.com logo
Join Slack
Powered by
I seem to remember someone posting a way to use th...
# suitescript
m
I seem to remember someone posting a way to use the HITC typescript typings in a vanilla JS project in VSCode using 
/// <reference path=""
. I can't remember the actual syntax and am struggling to get it working. Does anyone have this working? Slack Conversation
s
I recommend just trying a 
tsconfig.json
instead of cluttering your actual source code with typescript directives
m
@stalbert I'm happy to do that, but I'm still not sure how to get the intellisense working based on that
s
you're doing things differently than I if you're source is in JS but you want TS to still help you out
You could try starting with the tsconfig mentioned in the readme
if it doesn't work let me know. I'm not sure support for JS was even in typescript back when the tsconfig was done.
m
Yup, can't use TS due to other team members but I remember someone posting you can still benefit from intellisense
s
Yes, TS has supposedly become better and better at working with plain js - however that's a use case I haven't explored much since I just code in TS.
the main point in that 
tsconfig.json
example is the path pointing to where the hitc/netsuite-types live (i.e. under node_modules/...(
similar to the requirejs (amd) paths capability.
but for directing typescript where to look for type definitions
a
Not using HITC, I seem to recall people saying they were able to download the suitecscript API from the file cabinet and somehow get intellisense from that
s
I think the webstorm plugin comes with some sort of intellisense support - you could try that. Again, I'm full TypeScript for type resolution which I think is the best of breed.
a
There is also a vscode extension SuiteSnippets, but I haven't really used it that much, as I use TS
m
Thanks all for your comments. I believe I got this working by adding
Copy code
"allowJs": true,
"checkJs": true,
to the 
tsconfig.json
from the hitc project and then using in script as follows:
Copy code
/**
 * @typedef { import("N/types").EntryPoints.Suitelet.onRequestContext } onRequestContext
 * @typedef { import("N/runtime") } N_runtime
 */

define(["N/runtime"], /**
 *
 * @param {N_runtime} runtime
 * @return {any} exports
 */ function (runtime) {
  return {
    /**
     *
     * @param {onRequestContext} context
     */
    onRequest(context) {
      context.response.write(`Hello ${runtime.getCurrentUser().name}`);
    },
  };
});
message has been deleted
s
ouch, it requires those '@typedef` tags?
I mean glad you got it working, bummer that you have to clutter up the source code with type related comments
You could bite the bullet and use TS so that the types are actually, well, types instead of code comments magically interpreted as types. 🙂
also with TS, no need to type your parameters in JSDoc since it's typed in the code?
m
Yeah that's the best I can come up. I've used TS for years in a previous workplace but unfortunately I'm not in a position to use it at my current job
d
@michoel I think the piece you might be missing is for JS projects use the documents *js*config.json file instead https://code.visualstudio.com/docs/languages/jsconfig#_jsconfig-options once everything is setup correctly, in actual script files this is all you should need to leverage the typings :
here is the jsconfig we use (some elements may be unneeded since not actually running tsc etc.)
Copy code
{
    "compilerOptions": {
		"target": "es5",
		"module": "amd",
		"moduleResolution" :"node",
		"checkJs": true,
		"baseUrl": ".",
		"paths": {
			"N": ["node_modules/@hitc/netsuite-types/N"],
			"N/*": ["node_modules/@hitc/netsuite-types/N/*"]
		}
	},
	"exclude": ["node_modules"],
    "typeAcquisition": {
        "include": [
            "underscore",
            "jquery",
        ]
    }
}
m
Ah nice! I didn't realise you could just 
import
within the 
@param
directive. That looks much cleaner to me
d
hopefully that works if not will be happy to help anyone troubleshoot (mainly bc I selfishly want more people just using JS to contribute to that ts lib 🙂 )
we also put this 
globals.d.ts
at the root of our projects to provide access to global modules without explicit dependency inclusion :
Copy code
declare function define(...args: any[]): any;
declare function require(...args: any[]): any;

interface LogOptions {
    /** String to appear in the Title column on the Execution Log tab of the script deployment. Maximum length is 99 characters. */
    title?: string;
    /**
     * You can pass any value for this parameter.
     * If the value is a JavaScript object type, JSON.stringify(obj) is called on the object before displaying the value.
     * NetSuite truncates any resulting string over 3999 characters.
     */
    details: any;
}

interface LogFunction {
    (title: string, details: any): void;
    (options: LogOptions): void;
}

declare namespace log {
	var debug: LogFunction;
	var audit: LogFunction;
	var error: LogFunction;
	var emergency: LogFunction;
}

declare namespace util {
	function isArray(obj: any): obj is any[];
	function isBoolean(obj: any): obj is boolean;
	function isDate(obj: any): obj is Date;
	function isNumber(obj: any): obj is number;
	function isObject(obj: any): obj is object;
	function isRegExp(obj: any): obj is RegExp;
	function isString(obj: any): obj is string;
	function isFunction(obj: any): obj is Function;
}
I am not sure there is a better way than this ... but I am not a ts guru looks like is documented somewhat in this issue as well: https://github.com/headintheclouddev/typings-suitescript-2.0/issues/103
m
Thank you this is very helpful. If you are already a contributor to the project can I suggest editing the readme to document the setup for vanilla JS? If not, I'll try doing so when I get a chance
The import in 
@param
works, but eslint doesn't like it...
message has been deleted
d
yes, I have made some contributions, suggesting PR on README to make more clear that can be used with JS as well was something I had considered
interesting. we use https://github.com/gajus/eslint-plugin-jsdoc instead for some of the jsdoc validation, usually is some minor formatting thing my guess is we are overriding the specific rule that can be controlled more granularly via that plugin to allow non-standard param types
m
🤔
I was using 
valid-jsdoc
. Now I've changed to to 
eslint-plugic-jsdoc
and still complaining about the import syntax
Copy code
{
  "parserOptions": {
    "ecmaVersion": 2018
  },
  "plugins": [
    "jsdoc"
  ],
  "extends": [
    "eslint:recommended",
    "google",
    "prettier",
    "plugin:jsdoc/recommended"
  ],
  "env": {
    "amd": true
  },
  "rules": {
    "valid-jsdoc": "off"
  },
  "globals": {
    "log": "readonly"
  }
}
d
probably some variation on the highlighted portion specifically overriding/suppressing the last rule it is complaining about in your case
m
message has been deleted
Also next challange is how to get prettier not to mess up the jsdoc formatting
But I think I need to get back to actual coding now lol
😂 1
s
this all sounds like a lot of work to avoid TypeScript... but I do empathize @michoel with your situation
d
to be clear, my stance definitely is not to dissuade anyone from using TS with SuiteScript if they are in the position to do so, but just to improve the development experience of those in same situation of using JS exclusively :)
18 Views
Open in Slack
PreviousNext
Powered by