a top level directive for module declaration and usage (inspired by go's package/import directives)

[mkvlrn-cm42]

TL;DR

How about something like this?

// user_modules/advanced-math/multiply.js
declare module advancedMath;

export function multiply(a, b) {
  return a * b;
}

// user_modules/advanced-math/multiply.js
declare module advancedMath;

export function add(a, b) {
  return a + b;
}

// src/some/long/deep/path/file.js
use module advancedMath; // no path, no extension, just the module name as it was declared earlier

var twoPlusTwo = advancedMath.add(2, 2);
var twoTimesTwo = advancedMath.multiply(2, 2);

why?

Learning Go has me acting unwise. But code modularization in there just works with that whole package myPackage thing and, even though I strictly use Typescript with path aliases well defined that also just work, maybe there could be a simpler way to do this that is node "native" and based on some sort of convention?

I'm an idiot and I just thought I would share my line of thinking to see if smarter people would find something useful in my ramblings.

how?

In go you use package myPackage at the top of your file and whatever is exported from there is automatically part of that package. Then you just import that package elsewhere without going crazy with paths and file extensions, and have access to what the package exported.

So there's probably some mechanism going through all code, seeking where packages are defined and what is exported. I'm not gonna pretend I have any idea if this could even be implemented in node, but I assume a convention (or very minimal configuration) should be in place regarding code location.

user_modules

Yup, I think it would be cool to centralize this kind of module in a user_modules directory, to reflect what's really going on. Doesn't have to be in the root of the project, doesn't even have to be named exactly that, but any kind of convention would be great here. If there's really no consensus because of varying project structures, I suppose something like a key in package.json could work as well, like type is being used now, so:

// package.json
{
...
  "type": "module",
  "user_modules": "./src/my-modules", // defaults to ./user_modules
...
}

A module could span multiple files just by having the same declaration on each file, and would work just like another esm, with exported and non-exported members, etc.

The way I see it (again, I'm an idiot, so I'm probably not seeing that well), it could work as an opt-in kinda thing, no need to mess with whatever is going on nowadays with the esm x commonjs war. This would be a thing for people creating "regular" projects anyway, not libraries, but who knows?

So that's it.

[RedYetiDev]

I think this is an issue for either TC39 or TypeScript. WDYT @nodejs/typescript

[styfle]

See subpath imports and subpath patterns which sounds really similar to what you are describing.

Its been around since [email protected] so its widely supported now.

[ljharb]

Syntax changes like that can’t happen outside of TC39.

[RedYetiDev]

I've closed this discussion given that, but feel free to reopen