unable to import from installed library in node_modules without relative path

[trusktr]

#1679 got closed by the super ugly stupid stale bot (:robot::boom:• • • • :boom::gun:), so continuing here:

I just tried this on 0.19.5 and I still get an error:

import {...} from 'asdom/assembly/index'

> asc assembly/index.ts --target debug --exportRuntime --exportTable

ERROR TS6054: File '~lib/asdom/assembly/index.ts' not found.

 } from 'asdom/assembly/index'
        ~~~~~~~~~~~~~~~~~~~~~~
 in assembly/index.ts(9,8)

FAILURE 1 parse error(s)

This works though:

import {...} from '../node_modules/asdom/assembly/index'

Reproduction:

git clone https://github.com/lume/asdom.git
cd asdom
git checkout unable-to-import
npm install
cd example
npm install
npm run dev // ERROR

---

The following works, but TypeScript shows red squigglies and intellisense breaks because AssemblyScript projects are not set up by default to satisfy TypeScript node resolution:

import {...} from 'asdom' // red squigglies all over!

The following doesn't work in AS, but it is proper and TypeScript will see the correct imports and we will get working intellisense:

import {...} from 'asdom/assembly/index' // Intellisense works, but not AS

[trusktr]

Updated the reproduction to checkout a particular branch.

[dcodeIO]

If assembly is the base directory there, I think a working (for AS) import would be

import {...} from 'asdom/index'

while asdom/assembly/index would attempt to find asdom/assembly/assembly/index.ts. Perhaps that's the culprit we have been looking at here for a while, in that leaving out the assembly would allow it to compile, but is not TS compatible?

[yjhmelody]

@trusktr May be similar to this question MaxGraey/as-string-sink#1

[willemneal]

Why not just?

import {} from "asdom"

[trusktr]

but is not TS compatible?

Yep, that. Types not found in VS Code. Requires an exports field in package.json to also be compatible with Node-style imports, which TypeScript doesn't support yet.

Why not just?

import {} from "asdom"

A few reasons:

1. Some things are not exported from the index for various reasons.
2. That is still not compatible with TypeScript by default, breaks VS Code intellisense out of the box.
3. For TS/JS-portable code, importing from a package index/main file is bad practice: it imports everything by default and does not tree-shake like the AS compiler does out of the box. This means that by default (for example with native ES Modules) an end user will import everything from a library even if they use only 1% of the library. For example, the statement import {oneLittleThing} from 'some-huge-library' is not so good, especially with big libraries where you don't need everything, because the entire module graph will be imported unnecessarily (and with native ES modules this means more network requests).

[willemneal]

Does types: assembly/index.ts work for 2?

Some things are not exported from the index for various reasons.

So really this issue here is that we can't do asdom/submodule?

Also it sounds like tree shaking is very bad for TS/JS.

[JairusSW]

I have the same thing.

import { console } from '../node_modules/as-console/assembly/wasi'

Should be:

import { console } from 'as-console/wasi'

The ../node_module won't work well for people using different package managers (pnpm for example). :'(

[dcodeIO]

Seems to go into the direction of finding a better convention, and deprecating ascMain - no? :)

[willemneal]

You could keep ascMain for the cases where people don't want assembly/index.ts but regardless of having it as-package/subpackage should resolve to dirname(entry of as-package)/subpackage.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in one week if no further activity occurs. Thank you for your contributions!

[trusktr]

Not stale. 🤖💥• • • • 💥🔫