Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Support for package.json conditional exports map, for extra libs typings acquisition #4464

Open
2 tasks done
JulianCataldo opened this issue Apr 7, 2024 · 1 comment
Labels
feature-request Request for new features or functionality

Comments

@JulianCataldo
Copy link

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
  );
});
@JulianCataldo JulianCataldo added the feature-request Request for new features or functionality label Apr 7, 2024
@JulianCataldo
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality
Projects
None yet
Development

No branches or pull requests

1 participant