Comments (4)
This is intended.
If you want your shell to be built standalone you would have to change your remote declaration:
remotes: ['app1'],
To use something like promise-based remotes where the remote is only known at run-time.
Changing back to use remote.d.ts
just removes the type safety that was added.
So instead of getting the error at build time, you would get it at run time.
When you generate a host you can pass the --dynamic
flag for this to be set up. However, since the remote deployment can be customized we leave that implementation up to you.
npx nx generate @nx/react:host host \
--dynamic true \
--remotes myremote
from nx.
Thank for getting back to me @ndcunningham! Maybe I didn't explain well our use-case and the problem Nx introduced.
So this is a monorepo and we could have different teams owning different portions of the site, but all "links" known during build time. Say Team A manages the host/shell application while Team B manages a singular remote app1
. However, the individual team should be able to deploy separately. Meaning as Team A makes updates to the Shell and deploys, Team B could be "breaking" their code but a week out from deploying. Still Team A can go live with their modifications.
You're suggesting in this case, rather than having Shell know about App1 during build time (aka the known remote entry file location), make it known during run time with dynamic imports.
So it's a conciseness design and not a bundler defect that all remotes are "built" when the Shell/Host gets built? Seems like an anti-pattern of MFE.
from nx.
@bouncehead13 Not necessarily an anti pattern.
MFE is just a general term used for a technique that involves loading certain portions of the frontend application remotely.
It could be iframes for example.
What we have learned over the years of supporting MFE architectures boils down to two main use cases:
- Faster builds
- Independent Deployability
We optimized what we generate out of the box for faster builds, as that was the overwhelming majority of why people were reaching for MFE.
If your use case is Independent Deployability then you can still achieve it along with type safety.
- Make sure there are no implicitDependencies in your hostโs project.json file.
- Add
// nx-ignore-next-line
above the imports in your host for the remotes (this will remove any edge created in the project graph between the two projects)
With that being said, we would still recommend that if you redeploy your host/shell application, that you should redeploy all your remote applications.
Your shell may have bumped a version of a package that your already-deployed remotes also used, and now that package can no longer be shared. This holds true also for workspace libraries, wherein you could break singletons. I.e if you rely on a singleton source for application state shared across remotes, then you could introduce a runtime-only breaking change.
Whereas redeploying everything when shell is changed helps prevent these potential issues at runtime.
We would also recommend for general development practice that your applications should always be in a deployable state (even if itโs an old state, this could mean feature branches for individual remotes, or using a feature flag setup) when working with MFEs.
This also helps ease the deployment burden by knowing that you can always deploy everything without breaking production.
For example, if a security vulnerability was found in a package that all your host and remotes use, and you need to release a hot fix immediately to patch that vulnerability, itโs a simple case of adding the patch and redeploying everything.
from nx.
This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.
from nx.
Related Issues (20)
- "serve-static" target leads to endless loop in angular application HOT 2
- ๐ Angular buildable lib : `Can't find stylesheet to import`
- Remix recipe does not have `development` task HOT 1
- Production build (shell app) does not build remotes apps via host app build HOT 4
- release: too many authors in authors section HOT 1
- Generating a new library automatically edits nx.json by adding the nx-eslint plugin causing random performance issues HOT 3
- The following projects are defined in multiple locations (incorrectly triggered)
- nx-cloud start-ci-run unable to find dynamic-changesets.yaml HOT 1
- @nx/playwright ignoring --project argument
- Lerna (powered by Nx) Cannot read properties of undefined (reading 'projects') HOT 1
- Errors when attempting to configure storybook
- `nx migrate latest` fails on an Angular workspace: `Unable to fetch migrations for @ngrx/[email protected]`
- nx rollup build fails in CI without any useful error message
- npm install is flaky related to "nx" "post-install" native-bindings [includes full repo] HOT 3
- NX doesnt install on my Macbook
- `nx report` yield "Cannot convert undefined or null to object" error after upgrading from 14.8.6 to 15.0.0
- Module Federation SSR error: "Shared module is not available for eager consumption"
- Nx updates my Next version after creating a new application HOT 1
- nx reset --only-workspace-data (nx 9.2.x - 9.5.1) => Failed to reset the Nx workspace HOT 14
- `nx release plan` with a project containing a scoped npm package, and no project name creates a malformed plan
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nx.