microsoft / microsoft/monaco-editor
[Feature Request] Support for package.json conditional exports map, for extra libs typings acquisition
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 46.8k
- Forks
- 4.1k
- Avg merge
- 17h 58m
- Merged PRs (30d)
- 1
Description
Context
- This issue is not a bug report. (please use a different template for reporting a bug)
- This issue is not a duplicate of an existing issue. (please use the search to find existing issues)
Description
Actually, the only way for the TypeScript worker to pick up added libraries via setExtraLibs or addExtraLib is by using the main or typings fields inside the package.json file, or without a package.json, by using my-lib/some-file.js or my-lib/dist/some-file.js.
It works perfectly with the legacy method, but not with the newer exports field, which is very useful for achieving this kind of layouts:
exports: {
'.': {
typings: './dist/index.d.ts',
import: './dist/index.js',
},
'./foo': {
typings: './dist/foo.d.ts',
import: './dist/foo.js',
},
},
Then we can import like this: import 'my-lib/foo';.
This is also better than using barrel files, which are becoming an anti-pattern, because of the side-effects risks, for bundlers, browsers, CDNs…
I'm not 100% sure but all ATA (automatic types acquisition) mechanisms I tried are randomly breaking on some packages, maybe because of this limitation.
Actually with Monaco, it's not possible to consume a library subparts if it's under a dist., without resorting to single entry point with a barrel, or full, sound paths.
This is problematic because since Node 12, a lot of NPM packages are adopting the new practice while abandoning the older one, for legitimate reasons.
Monaco Editor Playground Link
Monaco Editor Playground Code
const libs = [
// koala
{
content: `
export declare const foo: "Hey";
`,
filePath: "/node_modules/@types/koala/lib.d.ts",
},
{
content: `
export const foo = "Hey";
`,
filePath: "/node_modules/@types/koala/lib.js",
},
{
content: JSON.stringify({
name: "koala",
version: "1.0.0",
// typings: "./lib.d.ts",
// main: "./lib.js",
// v--- NOT WORKING ---v
exports: {
".": "./lib.js",
},
type: "module",
}),
filePath: "/node_modules/@types/koala/package.json",
},
// tiger
{
content: `
export declare const bar: "Hey";
`,
filePath: "/node_modules/@types/tiger/lib.d.ts",
},
{
content: JSON.stringify({
name: "tiger",
version: "1.0.0",
main: "./lib.js",
type: "module",
}),
filePath: "/node_modules/@types/tiger/package.json",
},
// rhino
{
content: `
declare module 'rhino' {
export class Foo {
/**
* # Construct me!
*/
constructor(readonly hello: string) { } } }
`,
filePath: "/ambient.d.ts",
},
];
libs.forEach((file /* libs */) => {
console.log(file);
monaco.languages.typescript.typescriptDefaults.addExtraLib(
file.content,
"file://" + file.filePath
);
});
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the TypeScript worker's extra-library resolution through setExtraLibs and addExtraLib, using the linked Monaco Editor Playground reproduction. Compare the working main/typings package.json case with the exports case, including the my-lib/foo subpath. Done means extra libraries using conditional exports resolve their declaration files and the reproduction no longer fails.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js, typescript
- Domain
- developer-experience, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100