aleph.js

aleph.js copied to clipboard

add a importmap command to manage the import_map.json:

$ aleph importmap add @npm/react

  -> 17.0.1
  -  16.14.0
  -  16.13.1
  -  other

$ aleph importmap add std/hash
$ aleph importmap add aleph
$ aleph importmap add [email protected]/mod.ts --name aleph
$ aleph importmap add aleph --cdn nest.land
$ aleph importmap add @npm/[email protected] --cdn skypack
$ aleph importmap update

supported sources:

• npm packages via esm.sh
• deno.land/std
• deno.land/x

This could definitely become it's own /x/ package because of usefulness, but prob best to start off of small by keeping it here.

I could get working on this if no one else has started yet.

@kittywantsbacon cool, let's do it!

Currently I have this implemented:

Usage:
    aleph importmap [dir] <...options>

[dir] : Directory of the import map, defaults to current directory.

Options:
____________________________________________________________________________
    -a, --add    <moduleID[@version]>  Add a module to the import map.

        --name   <alias>             Alias to use in import map.

        --path   <address>           Manually specify the address to map to.
                                     Requires --name.

        --rolling                    (NOT RECOMMENDED) Don't pin module to a
                                     specific version (always latest).
____________________________________________________________________________
    -r, --remove <module>            Remove a module from the import map.
____________________________________________________________________________
    -u, --update                     Update all modules in the import map.

        --update <module>            Update a module to the latest version.

Supports esm.sh, deno.land/std/, and deno.land/x/ so far.

The command will query NPM and deno.land respectively to make sure the versions exist. It also queries deno.land to make sure the specific file/folder that is specified actually exists on that version.

I made some assumptions for deno.land module specifier resolution for now, it works like this:

• If the specifier ends with a '/', it's assumed to be an alias for a directory
• If the specifier ends with '.ts, it's assumed to be an import for a file
• If the specifier does not end in a '/' or '.ts', 'mod.ts' is appended to the end.
  • This should probable change, because if you forget to add the trailing slash when referring to a directory, the tool errors out and tells you the directory does not have a mod.ts in it. However, I don't know how much we want to magically resolve things, so I just left it like this for now.

Examples:

• moduleID@version/submodule -> address
• std/ -> https://deno.land/std@LATEST/
• std/hash -> https://deno.land/std@LATEST/hash/mod.ts
• std/path/posix.ts -> https://deno.land/std@LATEST/path/posix.ts
• [email protected]/hash -> https://deno.land/[email protected]/hash/mod.ts
• aleph/framework/core -> https://deno.land/x/aleph/framework/core/mod.ts
• @npm/react -> https://esm.sh/react@LATEST

I probably made other assumptions but this is a good enough mvp for now. Feedback appreciated!

@kittywantsbacon great job

do you think it's ready to merge?

@kittywantsbacon do you think aleph importmap -a react --npm is better?

I'm gonna make some more changes and then make a PR later this week.

For the command format I think either would be fine, but it should be consistent. So if we use @npm/ then we should also have @skypack/ and @nest/ or have them all as flags.

I suggest to make a VSCode plugin instead of a CLI, so it can access the import map automatically from already configured "deno.importMap" setting

I opened a discussion on exposing Deno's import map

• https://github.com/denoland/deno/discussions/12575