Open JulianCataldo opened 3 months ago
As a side note, maybe the lack of "moduleResolution": "Bundler"
(or "module": "Preserve"
) is the root cause of this.
For now, we only have those:
export enum ModuleResolutionKind {
Classic = 1,
NodeJs = 2
}
Also I'm not sure about how deep Monaco treats special files like tsconfig.json, package.json in the root project or dependencies, etc.
Context
Description
Actually, the only way for the TypeScript worker to pick up added libraries via
setExtraLibs
oraddExtraLib
is by using themain
ortypings
fields inside the package.json file, or without a package.json, by usingmy-lib/some-file.js
ormy-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: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