In ESM, a function is either limited to the module (file) or is globally available. Once a function or anything else is exported, anyone can import it. Do we have other granular levels? Why do I ask for this? We tend to take code cleanness to extremes. We break a big coherent file into smaller fi…

We don't want developers to do this: import { get } from "./path-to-database-get.js" const result = await get("some query") Rather, we want them to do this: import { db } from "./path-to-database.js" const result = await db.get("some query") We can create static code analysis for that of cours…

For example, consider this imaginary export: exportDir const get = async query => { } And this get method would be visible only for sibling files inside the same directory.

Every scope is a granular level of visibility/reachability. For your specific question, in node you’d do that by putting the database stuff in a package, with the exports field defined. In a browser, you’d probably want to use a bundler and not expose the individual modules at all.

I do feel like static analysis can be a useful way to solve this problem as well. I've been fond of dependency cruiser which lets you described arbitrary rules you would like enforced, such as "you can not import from a file starting with an underscore unless you are either in the directory containi…

@theScottyJam , that's an interesting npm package. The point is there would be no config file and no need for extra requests. I asked ChatGPT for a table of access modifiers in different languages: Language Modifier Scope Description C# public Accessible from anywhere internal Accessibl…

[image] Nefcanto: sibling files or from subdirectories The JavaScript specification has no notion of file locations or directories. Where the code comes from is up to the "host" environment.

Does this mean that the Node.js or the browser manages loading code from "directories and files"? Or in other words, does this mean that in theory I can create a host that loads code from database?

Exactly. The host determines what it means to import a particular string, if it's a filesystem path or a http url, or could be from an in-memory database. The core language does not specify.

That's an interesting architecture. However, there still needs to be some keyword to specify the scope of visibility. It's an abstract idea. Let's say I want to create a host that loads strings from database. My host sees this code: import { someModule } form "somePath" I will search my database …

Do we have other granular levels for visibility?

I have questions

aclaymore February 18, 2025, 4:31pm 8

Similar discussion here: Package Scope Proposal

Topic		Replies	Views
Package Scope Proposal 💡 Ideas	6	361	May 24, 2024
Module-Level Export Visibility: 'use internal' Directive or export internal Syntax 💡 Ideas proposal	2	195	May 7, 2025
Folder encapsulation - Encapsulated folders to be consumed 💡 Ideas proposal	9	510	October 8, 2022
Is it possible to remove function declaration for one-function-export-per-file? I have questions proposal	28	500	February 19, 2025
Protected support for `class` 💡 Ideas	25	1169	January 15, 2023

Do we have other granular levels for visibility?

Related topics