First-class package management support

[vgrichina]

What is the best way to add package management support to AssemblyScript?

I think that using existing package structure created by asinit (i.e. root of sources in assembly within npm package) is pretty good and we can go with it.

However I don't think there is any support for actually using the package without specifying whole path.
E.g. let's say I use https://github.com/MaxGraey/bignum.wasm. My understanding is that currently I'll have to specify full path to the module I need, i.e. something like:

import u128 from '../node_modules/bignum.wasm/assembly/integer/u128.ts';

I want to be able to do something like:

import u128 from 'bignum.wasm';

What is the best way to achieve this? Is there any way to specify module search paths when calling compiler?

[jtenner]

See my library https://github.com/as2d/as2d.
The developer has to require it from a relative path and use the typescript source directly for now.

Also, they need to add an included glue.ts source file in their compilation.

[dcodeIO]

(i.e. root of sources in assembly within npm package

Agreed, that seems like something we can do by means of implementing actual include paths with a node-like ./node_modules, ../node_modules etc. traversal that skips directly to the assembly directory within an npm package. Maybe together with an asMain entry in package.json that indicates the actual main file, falling back to assembly/index if not specified.

[MaxGraey]

It will be great also support URL as path to source like deno does (may be in future)

[vgrichina]

It will be great also support URL as path to source like deno does (may be in future)

I think the best would be if module resolver is abstracted out. So that I can provide custom function which for a given module path / URL returns module contents.

[vgrichina]

@dcodeIO @MaxGraey is it possible to prioritize this?

Another related question:

1. We generate binding files with .near.ts extension for some of our .ts files (using forked assemblyscript).
2. Ideally I think we want to hook into import handling, so that e.g. if imported module name is model.near we can kick off our binding generation for module model.ts and import resulting file. What's the best way to do it?
3. Binding generation is currently hacked together in definition.ts on our assemblyscript fork. I wonder if it makes more sense to have pluggable ExportsWalker implementation (or some other way to plug this in). WDYT?

[MaxGraey]

@vgrichina AssemblyScript support --transform flag which provide access to full AST tree after parsing. So I don't see any reason for fork. See usage example for applyTransform and after that you could attach this like asc ... --transform ./transforms/zome_function.js

[vgrichina]

@MaxGraey nice, I didn't realize that's a thing.

What if there is any error during parsing. e.g. some of dependencies cannot be resolved?

[vgrichina]

@MaxGraey @dcodeIO

What if there is any error during parsing. e.g. some of dependencies cannot be resolved?

In particular I'm thinking of following:

1. When module is imported – resolve it a-la Node.js looking into node_modules folders (assuming assembly prefix).
2. If module is somehow marked as needing bindings generations (ideally just by using annotations on classes) – it is post-processed using our custom transform (i.e. what happens now in definitions.ts in our forked AssemblyScript) and only after that imported.

What's the best way to implement this? At what stage is --transform applied, can it replace module being imported? How to hook into module resolution process?

[dcodeIO]

What's the best way to implement this? At what stage is --transform applied

The idea of transforms is that you can hook into anything you'd like to, with the only hook implemented currently being afterParse. We can add more such hooks of course, like one that is called once the program has been created with all compile-time information being present, one that is called to intercept command line arguments, you name it.

can it replace module being imported? How to hook into module resolution process?

That should be possible using some sort of hook as well, like one that intercepts any imports or a fallback that is called if an import is not found, so it can be filled in by the transform.

I think we should start by implementing node-like module resolve and once that's done add a suitable set of hooks for your use case.

[MaxGraey]

@dcodeIO When we talked about module resolving last time we decide use assembly/index.ts in first stage with fallback to asmain value in package.json. Also possible do it via our own asconfig.json I guess

[jtenner]

We should make a decision that is forward thinking and gives us options later. Some kind of asconfig might be useful.