Eric Burel

This might be a bad idea in the end, Mongoose model system is way easier to use than Mongo driver, which forces you to wait for the db to be...

Currently waiting for an "exec" like function to land, the first use case being local updates of packages during dev https://github.com/vercel/turborepo/issues/321

See monorepo setup of Blitz: https://github.com/blitz-js/blitz/pull/3129 and https://github.com/blitz-js/blitz/blob/main/packages/blitz/package.json#L12-L15

A solution could be to host a very minimal app directly within vulcan-npm, so it can test whether the packages are correctly imported (in Lerna, you don't really test this...

Added a first test that checks that the build did not erroneously load other packages (related to https://github.com/VulcanJS/vulcan-npm/issues/80 multi entry support in packages)

Next.js has it's own tree shaking function for removing SSR code from the client bundle: https://github.com/vercel/next.js/pull/27552 We could do something similar to remove `resolver` field from schemas client-side.

I've found out about a possible alternative, used by Symfony for instance: they put the app in the monorepo, but deploy a read-only repo for the actual app. This way...

https://stackoverflow.com/a/49799881/5513532 this seems to allow to publish a subtree of git as another repo I've started an Express starter, I'll use it as a test case before trying to move...

This article describe an alternative, using TypeScript "build" option. Maybe it could help getting rid of Babel and Webpack? Or at least improve our Lerna workflow: https://betterstack.dev/blog/lerna-typescript-monorepo/

## About the Express starter - Esbuild register currently lead to some issues with dependencies with weird exports: https://github.com/egoist/esbuild-register/issues/12 ```js Converting "require" to "esm" is currently not supported { column:...