|
| 1 | +## `@quarto/_*` vs. `@quarto/*` |
| 2 | + |
| 3 | +You might have noticed the presence of repeated packages like @quarto/mapped-string and @quarto/_mapped-string in this repo. |
| 4 | +Why do they exist? |
| 5 | + |
| 6 | +### Resolving packages from different projects |
| 7 | + |
| 8 | +The packages in `package/_*` (that is, with a leading _) are copies of their namesakes that lack underscores. |
| 9 | +They exist to allow code reuse among bundlers that don't agree in how to resolve modules. |
| 10 | + |
| 11 | +The files in `packages/_*/src/*.ts` will be identical to those in `packages/*/src/*.ts`, _except_ for the `imports.ts` file. |
| 12 | +This `imports.ts` file centralizes all the import syntax that must differ between the two package versions. |
| 13 | + |
| 14 | +Ideally, we would keep the common files across the two packages as symbolic links of each other. |
| 15 | +Unfortunately, symbolic links apparently trigger a compilation bug in `vite build` (which we use in apps/vscode-editor) where files end up being resolved from the wrong location. |
| 16 | +As a result, we are forced to maintain explicit copies that need to be in sync with each other. |
| 17 | + |
| 18 | +### packages/_* |
| 19 | + |
| 20 | +These packages are private, have no build steps and are "pure typescript". |
| 21 | + |
| 22 | +### packages/* |
| 23 | + |
| 24 | +The packages without underscore will have more typical package.json setups, and can be published directly to npm. |
| 25 | + |
| 26 | +## Other solutions |
| 27 | + |
| 28 | +Ideally we wouldn't need anything like this horrendous hack. |
| 29 | + |
| 30 | +We first experienced a problem trying to import a library like mapped-string from both inside apps/vscode-editor and from a typical npm library that uses mapped-string (like annotated-json). |
| 31 | + |
| 32 | +It is clearly possible to have a single library that can resolve correctly in these settings. |
| 33 | +Concrete examples are `ansi-colors` and `markdown-it`. |
| 34 | +We could learn how to make this technique work in our monorepo, but I believe that these libraries end "overbundling" some of their npm exports by running a bundler and pushing the bundled JS. |
| 35 | +I would like to avoid this problem because it causes a large degree of bloat in the resulting JS. |
| 36 | + |
| 37 | +Conclusion: we need to study the problem more. |
0 commit comments