Browser-based variant for direct use

[onsetsu]

Is your feature request related to a problem? Please describe.

We're working on a graphical editor as part of the larger web-based development environment lively4 (self-supporting, live programming, wiki-like):

We want to add type support via TypeScript to data-related edges in the graph for more efficient input and clearer visuals (e.g color ports and edges by type, instead of our steelblue placeholder).

While working with the TypeScript Compiler API would be manageable, ts-morph seems like a much better fit for non-file-based code such as ours.

Unfortunately, ts-morph seems not to be easily available to browser-based environments. As an example import {Project} from 'https://unpkg.com/[email protected]/dist/ts-morph.js' results in the following error:

Error: SystemJS error: could not load https://lively-kernel.org/lively4/aexpr/@ts-morph/common
  Instantiating https://lively-kernel.org/lively4/lively4-core/@ts-morph/common
  Loading https://unpkg.com/[email protected]/dist/ts-morph.js
  Loading workspace:9438ce51-a88e-4d03-b463-36579d41c73d/lively-kernel.org/lively4/lively4-core/unnamed_module_477b3665_e486_4631_b5ac_afeb81621f56

potentially, because @ts-morph/common and code-block-writer are declared as external dependencies with a "bundleDependencies": false.

Describe the solution you'd like

We like to use ts-morph via a simple drop-in, e.g. via a cdn or self-hosted. For this a simple bundled version of ts-morph would suffice (EcmaScript module format). Ideally, it would be non-minified to enable proper debugging and monkey patching to some degree.

As ts-morph likes its users to use their custom ts export instead of the typescript one, maybe typescript should be included in the bundle. I'm unsure here.

This issue seems to align with the general desire of using ts-morph in browsers (#171, #361, #364). To support this desire, ts-morph should be easily available to developers, instead of making all its users having to deal with the accidental complexity of JavaScript's modern eco system. For many developers, this might increase the appeal to try and toy around with ts-morph.

Describe alternatives you've considered

One alternative for us would be to fallback to the drop-in variant of typescript directly (e.g. https://cdnjs.cloudflare.com/ajax/libs/typescript/4.8.4/typescript.js).
However, this would entail writing our own wrapper that would mostly replicate the same/similar functionality ts-morph already provides.
Instead, we would like to use your library directly.

[milahu]

potentially, because @ts-morph/common and code-block-writer are declared as external dependencies with a "bundleDependencies": false.

what? where?

https://unpkg.com/[email protected]/package.json

  "main": "dist/ts-morph.js",
  "typings": "lib/ts-morph.d.ts",
// ...
  "dependencies": {
    "@ts-morph/common": "~0.17.0",
    "code-block-writer": "^11.0.3"
  },

https://unpkg.com/[email protected]/dist/ts-morph.js

var common = require('@ts-morph/common');

i guess this should be

import common from '@ts-morph/common';

ts-morph.js is the only file in dist/
so effectively youre asking for a ts-morph.esm.js ...?

workaround: use a bundler like vite to transform commonjs to esm

see also
https://github.com/search?q=ts-morph+filename%3Apackage.json&type=Code