Over the years, I have found npm link (which is what npm install <../relative/path> does behind the curtains, and why you need resolve: {symlinks: false}) to be unreliable to the point of uselessness. It never behaves like one would expect, and this is before taking into consideration any cross-platform issues. A more palatable native alternative is to npm pack the code in question and then npm install ../path/to/packed.tgz… but of course the problem with that is that you have to do it every time you make a change. Not-exactly-hot reloading.
It is for these reasons that frontend-build relies instead on Webpack’s resolve.alias, exposed to developers via module.config.js. It’s not perfect: the downside, as you point out, is requiring developers to create the file in the first place. But at least it behaves as one would expect… with hot-reloading, and without the need for --legacy-peer-deps or any of the other hoops you had to jump through.
All of this said, I think there’s value in what you outlined as an alternative to module.config.js. I’m just unsure about making it an official recommendation, yet. Defaulting to resolve: { symlinks: false } in webpack.dev.config.js is probably fine, but I have mixed feelings about legacy-peer-deps. It can save you in a pinch, but depending on it as a fundamental mechanism usually means there’s some bigger underlying problem.
For example, the reason you used it for - avoiding installation of peer deps - might not be the same reason the AI extensions plugin uses it (I don’t know why it’s needed there). The most common case is actually to avoid checking for dependency conflicts - which is a bad thing to rely on in production, as it can cause hard-to-debug runtime issues.
You can avoid having to stop the desired Tutor container by manually specifying which ones you actually want to run in the first place. For example, I usually start my dev environment with:
tutor dev start -d mfe
This means that none of the “mounted” ones start, so I don’t need to stop them later for npm run dev to work.
But yeah, if you want develop a plugin and don’t want to run the host MFE outside Tutor, the local build context that Felipe refers to might be your best bet. (It’s a neat idea - first I hear of it!)
Out of curiosity: did you try to use npm pack && npm install instead of npm install --legacy-peer-deps --install-links? (See the problem I have with --legacy-peer-deps, above.)
This is not the first time folks have noted that either (or both) the env.config.jsx syntax or the tutor-mfe syntax that uses it are more complicated than they need to be. We’re doing something about the first in frontend-base land, but this is the first time somebody comes up with something at the Tutor level. As a co-maintainer of tutor-mfe, I’d be interested in seeing a PR that actually does it. The idea is sound in principle. If you were to submit something like that, I’d be happy to review it!