Suggestion: making exports visible only to the same directory with JSDoc @package tag
## Search Terms JSDoc package directory package-private ## Suggestion If an export is annotated with `@package`, that export is visible only to files in the same directory. I can think of two levels of `@package` support: a soft one would remove these exports from auto completion if not visible. A hard one would also emit a compile error. See also: [Use JSDoc: @package](https://jsdoc.app/tags-package.html) ## Use Cases We organize source code using directory structure. We often make exports that are meant to be referenced only by sibling modules. However, JavaScript/TypeScript has no idea of scoping based on file system, so we are free to import such "local" exports everywhere. TypeScript could help us do file system-based scoping. ## Examples ```ts // ----- src/foo/bar.ts /** * @package */ export fooBar = "fooBar"; // ----- src/foo/index.ts // Can import fooBar from "./bar" import { fooBar } from "./bar"; // ----- index.ts // CANNOT import fooBar from "./foo/bar" import { fooBar } from "./foo/bar"; ``` ## Checklist My suggestion meets these guidelines: * [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code * [x] This wouldn't change the runtime behavior of existing JavaScript code * [x] This could be implemented without emitting different JS based on the types of the expressions * [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.) * [x] This feature would agree with the
Posted by uhyo on Nov 6, 2020, 2:52 AM
Tags
Related issues
- I hate that this whole cluster of beliefs exists, but software on my own computer enforcing what I can and can't do for ideological reaso...
- As I replied in another comment[1], it's their software, their choice.
- [Feature] Support external model integration via personal API keys and local LLMs (BYOK)
- > So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
- Feature request: support multiple named accounts per app/connector
- Support standalone Windows installer (`codex-setup.exe`)
Raise real-world problems, find people facing the same issue, and discuss solutions.3,000 issues0 comments
support (SaaS)
I hate that this whole cluster of beliefs exists, but software on my own computer enforcing what I can and can't do for ideological reaso...
NewAs I replied in another comment[1], it's their software, their choice.
[Feature] Support external model integration via personal API keys and local LLMs (BYOK)
> So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
Feature request: support multiple named accounts per app/connector
Support standalone Windows installer (`codex-setup.exe`)
[feature]: Move OIDC back to self-hosted OSS(Plane Free)
I was running about 1000 machines on VMware in my previous career.
Suggestion: making exports visible only to the same directory with JSDoc @package tag
## Search Terms JSDoc package directory package-private ## Suggestion If an export is annotated with `@package`, that export is visible only to files in the same directory. I can think of two levels of `@package` support: a soft one would remove these exports from auto completion if not visible. A hard one would also emit a compile error. See also: [Use JSDoc: @package](https://jsdoc.app/tags-package.html) ## Use Cases We organize source code using directory structure. We often make exports that are meant to be referenced only by sibling modules. However, JavaScript/TypeScript has no idea of scoping based on file system, so we are free to import such "local" exports everywhere. TypeScript could help us do file system-based scoping. ## Examples ```ts // ----- src/foo/bar.ts /** * @package */ export fooBar = "fooBar"; // ----- src/foo/index.ts // Can import fooBar from "./bar" import { fooBar } from "./bar"; // ----- index.ts // CANNOT import fooBar from "./foo/bar" import { fooBar } from "./foo/bar"; ``` ## Checklist My suggestion meets these guidelines: * [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code * [x] This wouldn't change the runtime behavior of existing JavaScript code * [x] This could be implemented without emitting different JS based on the types of the expressions * [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.) * [x] This feature would agree with the
Comments (0)
No comments yet. Start the discussion.