Please allow for vanilla javascript

[tiagorangel1]

I would love to use this, but the app I'm working on uses vanilla javascript. No frameworks, no fancy stuff.

[flatsiedatsie]

Related: #87

[davidmyersdev]

@tiagorangel2011 I'm not sure what you mean. The core library is already built to work with vanilla JS.

[flatsiedatsie]

That's wonderul news.

Could you perhaps create a tiny example for that use case? How would I use the library to generate a minimal text area and UI?

[tiagorangel1]

Using the HTML provided in the README results in a error (see #87)

  <div id="editor"></div>
  <script type="module">
	  import { ink } from 'https://esm.sh/[email protected]';
	  ink(document.getElementById('editor')!);
  </script>

[flatsiedatsie]

Using the HTML provided in the README results in a error (see #87)

  <div id="editor"></div>
  <script type="module">
	  import { ink } from 'https://esm.sh/[email protected]';
	  ink(document.getElementById('editor')!);
  </script>

Yes, that was the exact same issue I was having: #87

[davidmyersdev]

@tiagorangel2011 @flatsiedatsie it sounds like there might be an issue with the esm.sh service then. If you install it via NPM, I think it would work. I'll open this back up to investigate that service though.

[flatsiedatsie]

Wonderful, thank you!

Would it perhaps be possible to provide a single-file version of the library? For privacy protection reasons I can't use a CDN, the library files must be provided from the same server as the rest of the project. I've tried downloading the files form ESM, but that's quite hard to do, because it links to many other files, and those link to yet more files, etc.

[davidmyersdev]

@flatsiedatsie a single file version might be possible, but it would be pretty large due to the various dynamic imports that are used for code block language parsers, optional features, etc. It'd be better to install it via NPM and bundle it with something like Vite if that's possible.

[tiagorangel1]

how am I supposed to link it after installing with npm? this:

<div id="editor"></div>
<script type="module">
  import { ink } from '/node_modules/ink-mde/dist/index.js'
  
  ink(document.getElementById('editor'))</script>

plus basic HTTP server returns in error Uncaught TypeError: The specifier “solid-js/web” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.

sorry I'm kinda of a noob when it comes to this kind of stuff. I really don't want to use anything like vite

[flatsiedatsie]

@davidmyersdev Thanks

It'd be better to install it via NPM and bundle it with something like Vite if that's possible.

Unfortunately that's not possible. I'm trying to integrate it into an existing plain JS project. And like the poster above, I know nothing about Vite either.

it would be pretty large due to the various dynamic imports

That's no issue. The project loads multiple gigabytes of AI files (.gguf) to the browser, so large is very relative in my case :-)

[jmacdonald]

I'm having a similar issue, although I'm approaching it slightly different, which may help.

I'm building a new Rails 8 app, and in a similar fashion to others in this thread, am explicitly avoiding JS build tools. However, rather than linking to a CDN directly from the browser, I'm using importmap-rails. In a nutshell, importmap-rails is doing the following when I ask it to grab ink-mde as a dependency:

1. querying jspm.org to find the latest version of the package
2. downloading the package and any transitive dependencies to a vendor/javascript folder
3. generating an import map, allowing shorthand import { wrap } from "ink-mde" syntax in JS modules I'm writing
4. serving the mapped assets locally, from the vendored assets in step no. 2

This process works fine, but when I go to actually use the ink-mde module, I get a 4xx error as the top-level module uses a relative import that fails to resolve. In fact, the ink-mde module is actually quite small; here's the module in its entirety, expanded for added readability:

import "solid-js/web";
export {
    j as appearanceTypes, u as
    default, s as defineConfig, l as defineOptions, c as definePlugin, K as hydrate, u as ink, Y as inkPlugin, J as plugin, W as pluginTypes, a as render, f as renderToString, Z as solidPrepareForHydration, m as wrap
}
from "../_/zGxE9cTJ.js";
import "@codemirror/language";
import "@codemirror/state";
import "@codemirror/commands";
import "@codemirror/view";
import "@codemirror/lang-markdown";
import "@codemirror/language-data";
import "@lezer/highlight";
import "solid-js";

The "../_/zGxE9cTJ.js" path is the part that fails, which makes sense, since I don't have that asset vendored locally. I'm not exactly clear on how importmap-rails navigates/downloads relative dependencies like that, or if there is a prevailing standard for specifying related files in some top-level manifest for your package, but something along these lines is failing, and it may be related to how the ink-mde package is configured, compiled, and then served on JS CDNs.

[davidmyersdev]

@jmacdonald do you think you could share an example repo for your use case? I think I can fix these issues by creating a new build, but I'd like to verify with the import map case too.

[jmacdonald]

Yup, here you go.

Since posting the original issue, I have found a workaround. To help illustrate, I've created two branches with differing approaches:

• importmap-pin contains the result of running bin/importmap pin ink-mde, which is what I'd done when originally commenting on this issue, which (incorrectly) refers to the missing asset I described
• browser-pin is an alternate approach that skips using bin/importmap and instead adds the esm.sh URL directly to the import map

The browser-pin branch needed a ?bundle parameter on the esm.sh URL, which would otherwise raise this error in the browser:

Unrecognized extension value in extension set ([object Object]). This sometimes happens because multiple instances of @codemirror/state are loaded, breaking instanceof checks.

I've created some just recipes to help you run the app and debug the importmap pinning behaviour. The just run command will boot the Rails app, which listens on localhost:3000 by default. Visiting the root URL will load a basic page with a <textarea> and try to wrap that using your library.

If you want to try re-pinning your library, checkout the main branch and run just pin ink-mde, which will run bin/importmap in the container, vendor the assets, and update config/importmap.rb with the associated (local) assets.