autoimport doesn't work, make modules export default, and remap them.

[Mlocik97]

Doing

import search from 'N/search';
export default search;

allows autoimport to work properly,... if we don't re-export as default modue, instead import search from 'N/search'; it completes import { search } from '@hitc/netsuite-types/N'; that is incorrect in scope of NetSuite. Even tho, types loads correctly. Making it default export on level of N/module would allow to autocomplete work the way, NetSuite would be able to load modules correctly without any need of wrappers... I think we can achieve it by using namespace per module that will hold all interfaces and exports as default (even tho I may be wrong).

Now I have crazy shitty code, where I needed to exclude whole package from jsconfig as well as use autoImportExcludePatterns, and instead write multiple layers of re-exports and aliases to make autocomplete works correctly, but it break type-checking, and in result every module contains only default export of itself, because this package has cyclic alias.

If needed, I can help. Anyway, existing exporting is breaking autoimports.

[MrRob]

Hello,

I am not quite understanding what this is trying to accomplish. Can you give me an example of how you/why you would use this in a SuiteScript?

Thank you!

Robbie

[gabrielgortabns]

Hello, I send you invite to our repo,... it's if you try to write reco| (| is position of cursor), intellisense will suggest autoimport record, if you press tab, you will get:

import { record } from '@hitc/suitecloud-typings/N';

instead

import record from 'N/record';

[MrRob]

Ah, yes, I see what you mean about the auto import. That is slightly annoying, I never thought there might be a way to solve it, I just make a point not to use auto import. But if you know how to solve it, feel free to submit a pull request here! Also to make sure we're on the same page, here are a couple of videos showing how we use this module in TypeScript:

1. Old non-SDF style: https://youtu.be/xsGxUhYo9WI?t=996
2. SDF: https://youtu.be/czp9Kn1p2oo?t=678

[gabrielgortabns]

sry for long delay, I've started to work on this.

[ShawnTalbert]

One thing I noticed is in the first few seconds on your 2nd video the import syntax used seems to result in immediate compilation errors (red squiggles)? We use the more standard syntax like import * as foo from 'N/foo' (which is also the syntax shown in the README.md :)) as it is JS standard? (allowing TS to compile to the correct target module system). So if NS changes the module system in the future, hopefully we don't have to change all our imports across all the code.

[gabrielgortabns]

Doesn't seems like... but when I change how types are exported in node_modules, then it works correctly. But it's needed to be exported as default, and had exports correctly set in package.json

[ShawnTalbert]

We may want to review how the types are exposed generally.

I have multiple use cases where our projects use paths to map to types and 'auto import' works great with webstorm.

For example, we'll sometime want to do a mapping to NFT record types to make importing paths shorter/convenient.

{
  "paths": {
    "RecordTypes/*": [
      "../../FileCabinet/SuiteScripts/RSM/SS2/RecordTypes/*"
    ]
  }
}

The above allows me to write something like:

const so = new SalesOrder()

and webstorm will automatically add the import like this:

import { SalesOrder } from 'RecordTypes/Salesorder'

The question is, why does that paths mapping automatically pick the correct mapped path but our N/ path doesn't?

[gabrielgortabns]

I think I know answer.... while ../../FileCabinet/<and whole path> is in same scope of package (under same package.json scope) it just works, but for dedicated package with it's own package.json it doesn't if package.json of that package doesn't contain exports property. See: https://www.typescriptlang.org/docs/handbook/esm-node.html#packagejson-exports-imports-and-self-referencing