Support for monorepos, typescript paths & project references

[martaver]

Last I checked, snowpack broke badly in a monorepo environment. I have a monorepo with yarn workspaces linked by typescript project references.

Ideally, snowpack would be able to detect node_modules that are yarn workspaces (you can dereference the symlink and check whether the path contains node_modules) and build & serve them as web modules. And watch them too.

Likewise with typescript project references.

Snowpack actually has an edge in this regard because there's no bundling, the whole process could (potentially) be so much simpler... e.g. walk dependencies and run esbuild on each one.

It would be so refreshing to have a fast dev environment that just 'works' with monorepo features.

[FredKSchott]

We do support monorepos, and our test suite is actually run on a monorepo!

[martaver]

Here's a repro: https://github.com/cleric-sh/repro/tree/snowpack-monorepo

It's a SPA that references a 'common' package, in a yarn workspaces setup.

It builds, but there's no HMR when editing 'common'.

[airtonix]

dunno, maybe things were different back then, but nothing about this branch you've linked says "mono-repo" to me. it really just looks like a "single app repo"

[martaver]

Here's another repro that uses ts project references. https://github.com/cleric-sh/repro/tree/snowpack-ts-project-references

With ts project references, the outDIr and rootDir compilerOptions are used to map the package.json's main field back to the source entry.

tsc --build works fine... snowpack dies hard.

[FredKSchott]

Ah, yea I see what you mean. Right now we support monorepos (will need to look into https://github.com/cleric-sh/repro/tree/snowpack-ts-project-references to see if it's a bug) but you're right that symlinked packages aren't treated as source files, with full HMR.

In Snowpack's model, packages are treated as both "things that don't change often" and "code that must be more processed, since we can't trust that the package author used ESM vs. CJS or an older, non-web native format". This is why we don't support full source-code-like development for symlinked packages by default.

But, if there's enough interest, we can look into this more as a feature/enhancement.

[Poorva17]

We will be happy if snowpack incorporates this feature where symlinked packages are treated as source files, with full HMR.
In our project, we are having monorepo with 2 packages (we are using yarn workspace feature). We want changes in one package to be reflected in another packge like treating it as source files. This is not happening as you pointed out, symlinked packages aren't treated as source files.

[Bec-k]

Same here, we use lerna and webpack/tsc for now, but that have proven to be very slow.

[Bec-k]

Plus the dependencies tree must be respected by the builder, that's why we use lerna.

[crobinson42]

Absolutely interested in this. The need for HMR in local common/shared package development is a necessity in today's landscape.

[martaver]

I think the standard approach to determining whether a package should be HMR'd is to dereference the symlink, and then test whether the path has 'node_modules' in it. If not, then its a workspaces, and should be watched for changes.

…

On Tue, Nov 10, 2020 at 5:22 PM Poorva Gokhale ***@***.***> wrote: *We will be happy if snowpack incorporates this feature where symlinked packages are treated as source files, with full HMR.* We are also having monorepo with 2 packages (we are using yarn workspace feature). We want changes in one package to be reflected in another packge like treating it as source files. This is not happening as you pointed out, symlinked packages aren't treated as source files. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#938 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOXAMRLQRDVCW62YMBJPCDSPFLBXANCNFSM4QMVOZYA> .

[crobinson42]

I don't agree w/ the strict check for node_modules - also, snowpack wouldn't want to vendor lock a specific algo/check to yarn workspaces. Snowpack should probably just give the user the option to config this, IMO.

[hlege]

We also use a yarn 2 monorepo, and we would like to use snowpack 2 but right now we always need to start dev server with --reload, and in our case its 50+ sec, if any local package is changed (In standard development its change a lot). Its unusable in our case. All of our local package build with rollup to emit esm format. If snowpack can detect that and just use it it will be awesome. In yarn 2 there is no node_modules for dependencies cause its use .pnp.js.

So to detect it is a local package:

• package.json dependencies version number contains workspace: eg: "myLocalPkg": "workspace:pathToLocalPkg",
• package.json dependencies version number contains file: eg: "myLocalPkg": "file:pathToLocalPkg",
• package.json dependencies version number contains link: eg: "myLocalPkg": "link:pathToLocalPkg",
• path not contains .yarn/.cache or node_modules
• path not inside a zip archive (In yarn 2 all node_modules package stored as a ZIP archive eg.: .yarn/.cache/jquery-npm-xxx.zip )

[JochenDiekenbrock]

I'm trying out snowpack on an existing lerna/yarn 1 monorepo and I seem to be missing something pretty basic.

The app I try to start is a pretty generic react typescript app in a directory apps/my-app. When I run yarn snowpack dev in this directory, I get an the error [snowpack] Package "@testing-library/user-event" not found. Have you installed it?

To fix this, I can put an alias "@testing-library": "../../node_modules/@testing-library", into the snowpack config. But of course I would have to do this for every dependency, which would result in a huge alias list.
What am I missing?

[zhusjfaker]

Because the expressive power of alias in snowpack is relatively poor, we can use the transform plugin to realize the function of moneepo

[zhusjfaker]

import { aliascalculation } from './babel';

/**
 * 插件的导入方法
 *
 * @export
 * @param {*} _snowpackConfig
 * @param {*} pluginOptions
 * @return {*}
 */
export default function importalias(_snowpackConfig: any, pluginOptions: any) {
  return {
    name: '@byted/snowpack-import-alias-plugin',
    async transform({
      id,
      contents,
      fileExt,
    }: {
      id: string;
      contents: string;
      fileExt: string;
    }) {
      if (fileExt === '.js') {
        const result = aliascalculation(contents, id, pluginOptions?.config);
        return result;
      }
      return;
    },
  };
}

/* eslint-disable no-undef */
import generate from '@babel/generator';
import { parse } from '@babel/parser';
import traverse from '@babel/traverse';

interface IPackageConfig {
  /**
   * 命中包名称
   *
   * @type {string}
   * @memberof IPackageConfig
   */
  source_name: string;

  /**
   * 可替换包名称
   *
   * @type {string}
   * @memberof IPackageConfig
   */
  replace?: string;
}

/**
 * 转化源码
 *
 * @param {string} source 源码字符串
 * @param {string} id 文件位置
 * @param {IPackageConfig[]} config 基本配置
 * @return {*}
 */
function aliascalculation(
  source: string,
  id: string,
  config: IPackageConfig[],
) {
  const ast = convertast(source);
  handle(ast, config);
  const new_code = generate(ast, {}, { [`${id}`]: source })?.code;
  return new_code;
}

function convertast(origin_code: string) {
  /** 解析源码AST树 */
  const ast = parse(origin_code, {
    sourceType: 'module',
    plugins: [
      'typescript',
      'jsx',
      'decorators-legacy',
      'classProperties',
      'bigInt',
      'importMeta',
      'optionalChaining',
      'nullishCoalescingOperator',
      'importMeta',
      'optionalCatchBinding',
    ],
  });

  return ast;
}

function handle(ast: babel.types.File, config: IPackageConfig[]): void {
  const matchsource = (source: string) => {
    return config.filter(p => p.source_name === source).length > 0;
  };
  traverse(ast, {
    enter(path) {
      if (path.isImportDeclaration() && matchsource(path.node.source.value)) {
        const item = config.find(x => x.source_name === path.node.source.value);
        if (item?.replace) {
          path.node.source.value = item.replace;
        }
      } else if (
        path.isCallExpression() &&
        path.node.callee.type === 'Import' &&
        matchsource((path.node.arguments?.[0] as any).value ?? '')
      ) {
        const item = config.find(
          x => x.source_name === (path.node.arguments?.[0] as any).value ?? '',
        );
        if (item?.replace) {
          (path.node.arguments?.[0] as any).value = item.replace;
        }
      }
      return;
    },
  });
}

export { convertast, handle, IPackageConfig, aliascalculation };

[zhusjfaker]

const fs = require('fs');
const path = require('path');

const cwd = process.cwd();
const isTS = fs.existsSync(path.join(cwd, 'tsconfig.json'));

module.exports = {
  mount: {
    public: '/',
    src: '/src',
    '../swagger-analysis': '/swagger-analysis',
    '../aux-utility': '/aux-utility',
  },
  plugins: [
    '@snowpack/plugin-dotenv',
    [
      'snowpack-import-alias-plugin',
      {
        config: [
          {
            source_name: 'aux-utility',
            replace: '/aux-utility/es/aux-utility.js',
          },
          {
            source_name: 'swagger-analysis',
            replace: '/swagger-analysis/lib/swagger-analysis.js',
          },
        ],
      },
    ],
  ],
  devOptions: {
    port: 4000,
    open: 'none',
  },
  buildOptions: {
    sourceMaps: true,
  },
  installOptions: {
    installTypes: isTS,
    treeshake: true,
    externalPackage: ['aux-utility', 'swagger-analysis'],
  },
};

[dbousamra]

What is the status of this issue? I operate in a monorepo, and use typescript references to juggle compilation targets.

Snowpack doesn't track them as source files.

[Negan1911]

Hey, just came here with the same issue? Any news on how to track monorepo siblings as source code?

[edmulraney]

@Bessonov nice! You're right about needing to patch snowpack's typescript plugin to allow emitting. I've managed to get this branch working with support for both snowpack dev and tsc --build --watch. However, I now think that getting tsc --build working is not worthwhile. Snowpack already correctly reports all TS issues in monorepo siblings and nested dependencies without needing TypeScript project references to be setup. Furthermore, I believe tsc is either broken, or, by design, doesn't support showing all of the latest TS errors in packages which have project references which have failed to build in TypeScript. As a developer building a TS monorepo, I want to see the latest TS issues from all my packages, regardless of whether their TS dependencies have built successfully or not.

To get to that conclusion I tried to achieve the following:

• snowpack dev would run and always show the latest TS issues from any monorepo sibling (e.g. as your developing and changing the TS code you see the latest issue generated)
• tsc --build --watch would run and always show the latest TS issues from any monorepo sibling

Findings:

• With tsc --build --watch when multiple issues occur across multiple packages, tsc caches the older issues and only shows the latest TS issue. You have to fix the latest added TS issue before it checks again for the the other package's TS issues. Perhaps this is because TS won't produce new .d.ts files if there are TypeScript errors in a dependency?
• With snowpack dev snowpack performs as expected, in that it has the exact same behaviour as tsc --build --watch.

Conclusion:

• Don't use TS project references
• Don't use tsc manually
• Just run snowpack dev, you will see all TS issues in any monorepo sibling

I'm not that experienced with TypeScript however so may have configured it wrong. But that's the best I could come up with!

[Bessonov]

Furthermore, I believe tsc is either broken, or, by design, doesn't support showing all of the latest TS errors in packages which have project references which have failed to build in TypeScript.

OK, now I've got what do you mean. If both files are saved simultaneously, then you get only one error. If you fix one file and then break it again, you can get both compile errors:

10:51:45 PM - File change detected. Starting incremental compilation...
  
  ../launch-kit/src/setup/setup.tsx(11,8): error TS2741: Property 'c' is missing in type '{ children: string; }' but required in type 'SpecialButtonProps'.
  src/app.tsx(20,8): error TS2741: Property 'b' is missing in type '{}' but required in type 'SetupProps'.
  
  10:51:46 PM - Found 2 errors. Watching for file changes.

But personally I'm fine even with one message. It should be fixed anyway.

Don't use TS project references

I've no clue why it works without project references. If I run tsc --build --incremental --watch without project references, then it works as expected: tsc doesn't compile sibling modules. But with snowpack+tsplugin it detects changes even in sibling modules. How does it work? It's a bug or a feature? Does anybody know?

I'm feeling that it works sometimes even much faster with incremental compilation only in comparison to project references, nearly instant in 33% of cases. With this setup no patching of the plugin is needed. And both errors are reported, as you have said.

It seems like I've everything that I need to use snowpack in a monorepo with typescript and multiple react modules with and without project references. It's a game changer.

[edmulraney]

OK, now I've got what do you mean. If both files are saved simultaneously, then you get only one error. If you fix one file and then break it again, you can get both compile errors:

It's actually worse than this. You're right that you can see both compile errors by fixing one and then breaking it again, however, if you now fix the older TS issue (not the latest one shown), tsc will still show the old error. It appears to not recompile the older stuff until you address the more recent TS issue shown. This might be by design in tsc I'm unsure. But it's no good for development. I could have any number of TS issues in my packages and I don't want to be jumping back and forth from the terminal fixing one error at a time, errors that don't even apply to the package I'm trying to work in.

But with snowpack+tsplugin it detects changes even in sibling modules. How does it work? It's a bug or a feature? Does anybody know?

I believe this works because of snowpack aliases treating the other packages as one src input. We're effectively running the snowpack typescript plugin for ever typescript package. The output from this is then piped to a single STDOUT.

It seems like I've everything that I need to use snowpack in a monorepo with typescript and multiple react modules with and without project references. It's a game changer.

Yeah right! I was very impressed by how easy it was to get this up and running (without needing TS project references, or a complex tsconfig at all).

Nice tip on the --incremental optimisation. Thanks for the helpful discussion @Bessonov :)

[Bessonov]

You're welcome!

I believe this works because of snowpack aliases treating the other packages as one src input. We're effectively running the snowpack typescript plugin for ever typescript package. The output from this is then piped to a single STDOUT.

I can't deduce this behavior. Snowpack started for app package only. In ts-plugin I don't see any special treating for aliases, just one subprocess. Even the output of tsc suggest, that there is only one compiler and I don't see any duplicated messages. Or do you mean that snowpack creates a "virtual view" of directory structure? Any pointer on why/how snowpack/tsc works even without project references @FredKSchott ?

[edmulraney]

That's right, we don't do anything in tsconfig to get this to work - but in app package we use alias and mount in snowpack.config.js: https://github.com/edmulraney/snowpack-monorepo/blob/master/packages/app/snowpack.config.js#L6 Line 6 and 24. If you comment those out, app doesn't treat the siblings as source code :)

So it only works because we're in a monorepo where the source is co-located (and accessed relatively by snowpack)

[martaver]

Intuitively, it's probably walking the typescript references and treating them as source code instead of a module in node_modules. IIRC, the default behavior for node_module resolution is to dereference symlinks, and then check the path to see if it belongs to a 'node_modules' folder. If the path doesn't contain 'node_modules', then compiler treats the code as source, and proceeds to compile it. So in this way, for a monorepo that uses symlinks to treat projects as node_modules, such as yarn workspaces, typescript will happily compile the package and all related packages, because it treats them as a single package. The downside to this is that shared packages are re-compiled for each package that references them, and included in their output. This is different for project references, where tsc will walk the dependency hierarchy and any shared packages are compiled into their own dist folder once and only once. The output source is then treated as a stand-alone node_module by the projects/packages that depend on it. Overall, it would be worth getting project references fully supported in this capacity.

…

On Thu, Feb 4, 2021 at 12:06 PM Anton Bessonov ***@***.***> wrote: You're welcome! I believe this works because of snowpack aliases treating the other packages as one src input. We're effectively running the snowpack typescript plugin for ever typescript package. The output from this is then piped to a single STDOUT. I can't deduce this behavior. Snowpack started for app package only. In ts-plugin I don't see any special treating for aliases, just one subprocess. Even the output of tsc suggest, that there is only one compiler and I don't see any duplicated messages. Or do you mean that snowpack creates a "virtual view" of directory structure? Any pointer on why/how snowpack/tsc works even without project references @FredKSchott <https://github.com/FredKSchott> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#938 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOXAMQ2WADT5XTL2F5RVWTS5JWQTANCNFSM4QMVOZYA> .

[edmulraney]

The downside to this is that shared packages are re-compiled for each
package that references them, and included in their output.

I haven't confirmed it, but I don't think they'll be recompiled. tsc is running only once (via the snowpack typescript plugin) and is effectively running over your monorepo packages as a single codebase. It has no idea it's a monorepo or that the other packages aren't just a relative path with more source code. My guess would be that alias and mount in snowpack.config.js take precedence over checking node_modules. Perhaps @FredKSchott can confirm?

Edit: ah I think I understand what you're saying. If you make a change in components tsc will effectively recheck your non components packages as it's treating it as the same package to recompile. Now I get you. If this is a performance issue in large codebases (even with incremental builds enabled) then I agree with you that it would be worthwhile to use tsc project references in Snowpack (which we did successfully in the POC repo). Although, did you see my previous post regarding project references not appearing to recompile parent projects if a dependent project has a TS error? That is a broken developer experience IMO. I made a repro repo for that issue, completely separate from monorepos and snowpack: https://github.com/edmulraney/project-references-demo RyanCavanaugh/project-references-demo@master...edmulraney:master

[martaver]

Totally possible... my experience is merely anecdotal from trying to get fuse-box to play nice with ts project references :) I believe @ahnpnl <https://github.com/ahnpnl> also has some experiences trying to get ts-jest working with ts project references that might be helpful!

…

On Thu, Feb 4, 2021 at 2:02 PM Edward Mulraney ***@***.***> wrote: The downside to this is that shared packages are re-compiled for each package that references them, and included in their output. I haven't confirmed it, but I don't think they'll be recompiled. tsc is running only once (via the snowpack typescript plugin) and is effectively running over your monorepo packages as a single codebase. It has no idea it's a monorepo or that the other packages aren't just a relative path with more source code. My guess would be that alias and mount in snowpack.config.js take precedence over checking node_modules. Perhaps @FredKSchott <https://github.com/FredKSchott> can confirm? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#938 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOXAMWAH2DG6OKDLOEPTODS5KEGVANCNFSM4QMVOZYA> .

[adam-thomas-privitar]

This seems a pretty big deal as it affectively means those using TS cant use snowpack easily in a lerna or yarn workspace. Snowpack 3 very much does not work out of the box for multi-module projects.

Ive tried to understand all of the above but I'm struggling to read between the lines to see what the current workaround is, if there is one?

Do I need to:

• Setup aliases for each package in snowpack config?
• Setup paths manually in tsconfig?
• Give up?

[FredKSchott]

Hey everyone, really appreciate your patience on this one (and thanks @adam-thomas-privitar for the ping).

Snowpack was built on a pretty solid understanding that packages = static & built only once, which made monorepo support especially difficult to add on later. I just completed a big rewrite/cleanup of the Snowpack internals to specifically address this, which is now available at: #2707. Monorepo/workspace npm packages are now treated as source code by default, which means they get instant rebuilds on file change.

npm install snowpack@next

I'd love any help testing this, if you can check out this new version and run it in your project. If you run into any issues, please post in that PR.

This doesn't address the tsconfig automatic mapping brought up in the OP, but once this PR is settled and out I would be +1 for a PR to snowpack to automatically read aliases from tsconfig.json "paths".

[horacioh]

I tested Snowpack in a monorepo (v3.0.1) and it worked as expected!

https://github.com/horacioh/snowpack-monorepo/tree/main

is the next version supporting a different project structure than this one?

[Negan1911]

Yes, it will allow to treat sibling packages as source files, your monorepo compiles per-package instead.

[horacioh]

so I don't have to use TSDX or any compiler per project? it could be a simple file structure of esm code with a package.json?

[Negan1911]

Correct

[Bessonov]

@FredKSchott Thank you for the update! Can you please drop a line on how it works currently? I'm asking because it seems like it works already. From this comment:

I've no clue why it works without project references. If I run tsc --build --incremental --watch without project references, then it works as expected: tsc doesn't compile sibling modules. But with snowpack+tsplugin it detects changes even in sibling modules. How does it work? It's a bug or a feature? Does anybody know?

I'm feeling that it works sometimes even much faster with incremental compilation only in comparison to project references, nearly instant in 33% of cases. With this setup no patching of the plugin is needed. And both errors are reported, as you have said.

It seems like I've everything that I need to use snowpack in a monorepo with typescript and multiple react modules with and without project references. It's a game changer.

[JochenDiekenbrock]

I now had the time to test again and I came much further, the monorepo problem probably is fixed.
When I now start my (React) app with snowpack dev, I get an error message in the browser

Unhandled Runtime Error

SyntaxError: import not found: forEach

Source
http://localhost:8080/_snowpack/pkg/yup.v0.31.0.js [:5:17] 

The file <app-path>/node_modules/.cache/snowpack/development/yup@0.31.0/yup.js contains
import { getter, forEach, split } from 'property-expr';

Should I open a new issue for this or is there an easy fix?

[dbousamra]

Is there a canonical example repository that is failing?

[JochenDiekenbrock]

Now there is :-)

https://github.com/JochenDiekenbrock/snowpack-yup/branches

I narrowed it down to Snowpack version 3.1.0-pre.11. Branch update_to_3.1.0-pre.11 in the above repo fails with this error in the browser. Branch main with Snowpack ^3.0.13 works.

[dbousamra]

Beautiful, thank you. I will give it a try later.

[dbousamra]

@JochenDiekenbrock Hmm i am looking at this repo. How is it a mono repo using TS project references?

[JochenDiekenbrock]

Sorry, for the confusion, the "yup"-problem is not related to a mono repo, I just found it when testing with my mono repo

[horacioh]

FYI, I did a new repo with snowpack and a UI Library built with Typescript in a monorepo:

https://github.com/horacioh/snowpack-and-ui-lib-demo

maybe this can help to others too!

[Utsav2]

Snowpack seems to work with sibling packages now, but it doesn't seem to run esinstall on sibling package node_modules. Is this likely a misconfiguration on my end, or is that expected?

[crobinson42]

it doesn't seem to run esinstall on sibling package node_modules

I am experiencing this also.

…

On May 19, 2021, at 9:40 AM, Utsav Shah ***@***.***> wrote: Snowpack seems to work with sibling packages now, but it doesn't seem to run esinstall on sibling package node_modules. Is this likely a misconfiguration on my end, or is that expected? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#938 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNSMS3C6IX7GFWOZNFMJOLTOPSY5ANCNFSM4QMVOZYA>.

[Jamesernator]

I'm having similar issues, I've got a project structured similarish to monorepos and lerna (although using git submodules, but that's not actually the cause of the issue).

Basically I am wanting to keep my general library codes separate from repositories that use them as I share a number of libraries between components/projects a lot, as such I've been trying to move to a structure that uses local file: packages in npm to do this. I'm also using TypeScript project references so that libraries can compile each other effectively.

Now I've been trying to use some of this as a part of a Snowpack project but have been getting issues with the fact that Snowpack tries to resolve any node_modules as prebuilt packages even though the code lies within the same tree as other code for building.

I've made a sample repo to demonstrate what I mean: https://github.com/Jamesernator/snowpack-issue

In the repo I have a src/example-element.ts which loads a definition from a local package, the package defines a dependency "example-element": "file:src/packages/example-element/", and I try loading it with import ExampleElement from "example-element/ExampleElement.js";. However Snowpack tries to resolve the built file example-element/ExampleElement.js, however the built file doesn't exist because the typescript code hasn't been compiled for it.

What I expected to happen was, due to having a TS project reference, that Snowpack would compile the package prior to performing this resolution. Although alternatively it could equally well check on a failed lookup to see if there's a corresponding source file (which fits more in line with the single-file compilation).

My ideal behaviour would be that Snowpack compiles the src/ tree basically as-is, except resolving the imported local modules into corresponding paths. This would mean rather than treating local packages as things to bundle auotmatically, I could have more granular control over bundling/compilation and other such behaviour.

e.g. If we were outputting an import map (without bundling), this is the sort've I'd expect from the sample repo:

{
  "imports": {
    "example-element/": "./packages/example-element/"
  },
  "scopes": {
    "./packages/example-element": {
      "rxjs": "../path/to/.snowpack/rxjs.bundle.js",
      "example-library/": "./packages/example-element/packages/example-library/"
    }
  }
}

As mentioned by others, it shouldn't be particularly difficult to distinguish source packages from external, just check if the depdendency is file: and it's a subdirectory of the snowpack project.

[parkerault]

Something I haven't seen mentioned in this thread; I believe the primary benefits of typescript project references are 1. incremental builds for sibling dependencies; 2. language server "go to definition" links to the source file instead of the type definitions; and 3. languge server type checking on unsaved files in sibling dependencies. Number 2 is a constant gumption trap in my dayjob and I hate it. There are plenty of ways to do a build watch in a monorepo, but without native project reference support you don't get go to definition.

[gugahoi]

After reading this thread I am still confused. Here is the use case I have:

Folder structure

/app -- react app with typescript
/functions -- serverless functions with typescript
/admin-ui -- react app with typescript and snowpack
/service1 -- container based typescript api
/core -- type definitions shared across all folders

Each folder is it's own package but all import from core.

I've managed to get everything but "admin-ui", which is the one that uses Snowpack, working with the appropriate aliases to import from core (the shared module). Traditionally, I've used the compilerOptions.paths and references.path is tsconfig to allow typescript to autocomplete and find the correct definitions but this is not enough in Snowpack. So how would I go about configuring the equivalent in Snowpack?