UI: Should be simple it binds to dom, and can accept input and do certain actions 😄

Services: May want to test the Services mostly, like they can fetch commands and things 👍

Things like CTRL A, CTRL E, CTRL C etc... would be awesome!

relates to #41
relates to #36

This would be useful for implementing additional features on top of the base wasm-terminal package.

This could allow for things like saving modules to indexeddb, implementing custom callback commands (like updating cached modules, and searching for new modules), etc...

Cleanup TODOs and things, and general project architecture if needed 😄

Hey, this tool is awesome!

The examples work great on Firefox, but on Chrome I get a wapm shell error: TypeError: Failed to fetch error because of missing CORS headers:

Only tests stil broken are onces that want to transpile comlink from source. 😢 This should be fixed after the weekend

We have most implemented, but some don't really apply to our case, or have more complex implementations (Such as word jumping / deletion)

https://www.ostechnix.com/list-useful-bash-keyboard-shortcuts/

http://defindit.com/ascii.html

Something to show off the MVP of what it does / how to use 😄

The shell can't run rsign because some issue when transforming:

$ rsign
[INFO] Doing Transformations for "rsign"
wapm shell: parse error (CompileError: WebAssembly.compile(): section was shorter than expected size (648008 bytes expected, 647826 decoded) @+650103)

Maybe some cool image output, some memes, or maybe a game? 🤔

Don't know why this is broken now as well :(

Kind of related to #43

Should be super simple tests that just make sure bootstrapping the API works and can do simple things like read/write files 😄

While we are waiting for: rustwasm/wasm-pack#705

We should probably change the target from web, as it uses an import.meta that a lot of transpilers have a hard time with. That or transpile this, so that the import.meta is not called 😄

#45 (comment)

Right now it just shows the word Stdin. but it should show all stdout up to that point.

Just to make sure a command gets compiled and run, and can handle stdin.

Since this will become a monorepo with all wasmer js stuff. We should split up our packages and their respective demos. And change the build system to reflect that. 😄

Was thinking about this over the weekend. Would be easier to maintain, and make more sense to contributors.

I think we ran out of builds or something? Would be great to get this back up and running 😄

For running sub tests, we probably just want to run: npx lerna run test.

cc @syrusakbary

Should clean up the README so it stands out on its own. Has some simple Reference docs, with one or two, concise examples.

This should all be within the README. smile

Was broken by rollup's watch kinda borking out on me. Would be nice to fix! 😄 🎉

relates to #40
relates to #39

This needs to be done for #39 since we plan to publish this to crates.io and we need to be able to understand how to make a quick start 😄

Currently, all the contributing docs just outline the guidelines, but it would be great to say things like, how to install node, and the individual build commands and what they do 😄

Essentially, it should clean up the changes from #97 , and then merge some of the error naming and things from rsign-fix 😄

Should clean up the README so it stands out on its own. Has some simple Reference docs, with one or two, concise examples.

This should all be within the README. 😄

Should have both Rust, and Node / Browser examples and usage.

• Confirm packages look correct in Unpkg
• Confirm everything in npm's Readme looks good
• Test installing from npm and building a simple example works (90% done)
• Decide if we should expose WasmFs on Wasi object
• Allow Wapm Query to work anywhere
• Fix Travis / CI (originally #55 )
• Open Source this repo
• Publish Article
• Tweet the tweets
• Write denoland/deno#3005

Something as simple as a hello world the user can load and confirm that it works 😄 This should probably be done for the browser

Right now, we are doing i64 to i32 lowering always because Browsers don't currently support calling a function with a i64 signature.

However, in a few months browser WebAssembly implementations will support it (and Node as well), therefore we should check if i64 function calls are supported and in case is not, lower it.

How we can check it?

1. Create dummy WebAssembly file with a i64 signature that returns an i64
2. Try to call it. If it succeeds, then it works otherwise we use our "polyfill lowering the i64s"

Should use https://github.com/xtermjs/xterm.js/tree/master/addons/xterm-addon-web-links

Essentially, just a webpage that loads it, not using a JS framework.

Probably a known issue but it would be nice to support multiple pipes. 😄

Currently it seems it only considers the first pipe, e.g.:

$ md5 "test" | cowsay
 __________________________________
< 098f6bcd4621d373cade4e832627b4f6 >
 ----------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
               ||----w |
                ||     ||
$ 
$ echo -n "test" | md5 | cowsay
098f6bcd4621d373cade4e832627b4f6
$ 

This is for firefox and safari 😄

Seem's like something got weird with the flags?

The Browser compatibility section of the README describes issues running blocking code on the browser's main thread. Have you considered using Binaryen's asyncify pass to enable these applications to run correctly?

That way we don't get garbled text in continued prompts:

depends on #91

https://unix.stackexchange.com/questions/122977/what-is-the-correct-name-for-the-command

E.g echo "a" > x.txt

Should be much faster 😄

xtermjs/xterm.js#1790

One of our high priority items is each individual API of each package should be clean, and needs to be considered and thought out. And tested through the tests / examples we produce 😄

In a normal shell, the env vars $LINES and $COLUMNS are set with the lines and columns for the given shell.

echo "$LINES - $COLUMNS"

Ideally, we will have this environment variables working as well in the Wasm Terminal / WASI shell

It was suggested by @syrusakbary that we base64 encode some of our wasm assets for a better developer experience.

Where we agreed it is the less complicated devex, I countered it is not something we should do by default:

1. Base64'ing large assets (like our wasm files), will add The wasm file size, plus an additional 33% of the wasm file size, to our bundle size.

2. Including the assets in the bundle will slow down our time to first paint, as it will still be downloading our bundle

3. It will not allow our app to progressively enhance over time and introduce features as we need them.

Thus we decided this should not be the default build, but instead be some sort of development build, meant for hitting the ground running, but not for production.

Should clean up the README so it stands out on its own. Has some simple Reference docs, with one or two, concise examples.

This should all be within the README. smile

Should clean up the README so it stands out on its own. Has some simple Reference docs, with one or two, concise examples.

This should all be within the README. 😄

I guess some additional things were broken in #22 😢

Would be super awesome if commands that are piped, or all commands run in a single session, operated on the same file system.

However, this requires:

• Ripping out the specific stdin/stdout code.
• Creating one WasmFs that is passed into the terminal on contruction, and passed all the way down to the command runner.
• Having the Command runner create copies of the wasmFs object (Comlink should be able to do this because it is awesome 😂 ) that is passed to each web worker, and then synced back to the main wasm fs once the command finishes 😄

Could be as simple as a page that loads the file system, and runs some commands on the file system within wasi (Possibly an ls wasm module?)😄

When I follow the quickstart, I have a 404 error.

The steps I have followed :

• clone the repo
• npm install
• npm run dev
• --> Error 404

The problem is that 'npm run dev' launches the 'npx serve dist/' command and the 'dist' directory is empty.
I succeeded to run the example only after a 'npm run build' which generates js... in dist directory.

I don't know where is the problem (if we need to update scripts or update documentation) but I can help if you want :)

We Should have a less complex that the wasm terminal example to show that builds on top of the other 3 examples.

Such as a hello world a user can set up with the transformer package, wasi package, and wasm fs package in the browser.

We Should move the wasm shell example to it's own website.

• It should be a desktop installable PWA, which we could probably easily accomplish with preact-cli.
• It should work offline, included pre-downloaded wapm modules.
• It should have it's own javascript based callback commands for special features (Like listing all installed wapm packages).
• Wapm website should point to this shell.

Should cover the announcement, shouts out to devsnek, and some technical challenges.