Closed MichaelDeBoey closed 8 months ago
I came here for this after trying Remix yesterday. It seems perfectly suited to Nx.
Someone 5 days ago started this repo https://github.com/remix-nx/remix-nx let's watch the progress ๐
I believe @vsavkin already stated in his tweet about remix support. https://twitter.com/victorsavkin/status/1468668189894656000
For those tracking here, it appears that the Remix plugin is in beta! https://www.npmjs.com/package/@nrwl/remix
And I believe the package is developed at https://github.com/nrwl/nx-labs/tree/main/packages/remix
Apparently can't import libraries defined in tsconfig.json
in remix.
The error I get:
[1] The path "@my-org/ui" is imported in app/routes/index.tsx but @my-org/ui is not listed in your package.json dependencies. Did you forget to install it?
[1] ๐ฟ Built in 500ms
[1] Remix App Server started at http://192.168.126.251:3000
[0]
[0] Rebuilding...
[1] Error: Cannot find module '@my-org/ui'
update: so apparently for remix we must use "file:" protocol to import/install monorepo libraries in package.json:
"@my-org/ui": "file:libs/ui/dist",
And the problem now is that yarn install
won't work at first run because "@my-org/ui"
is not available at first run.
FWIW if I manually add the alias to theapps/remix-app/tsconfig.json
for my Remix app within my Nx monorepo it works, but the alias has to be prepended with a ~
.
So something like this:
"compilerOptions": {
"baseUrl": ".",
"paths": {
"~/*": ["./app/*"],
"~my/nx-lib": [
"../../../libs/nx-lib"
],
}
Ah, but this falls apart when you use the normal Nx path alias reference (@) in a lib using the path alias like I described above.
But it seems if I just adopt using ~
instead of @
across my entire monorepo, it may work. And that's not a huge deal right?
FWIW if I manually add the alias to the
apps/remix-app/tsconfig.json
for my Remix app within my Nx monorepo it works, but the alias has to be prepended with a~
.But it seems if I just adopt using
~
instead of@
across my entire monorepo, it may work. And that's not a huge deal right?@joe307bad
Thanks for pointing this out! I'm still learning Remix, so this is a golden nugget of information that I'll keep in my back pocket. In the meantime I'll be using this workaround until the Remix team fixes that issue.
I have found a work around. If you go to your tsconfig.json
file in the remix app created by the plugin, remove the "paths" object and extend the base config. This will make things work.
My current working tsconfig.json
in my remix app:
{
"extends": "../../tsconfig.base.json",
"include": ["remix.env.d.ts", "**/*.ts", "**/*.tsx"],
"compilerOptions": {
"lib": ["DOM", "DOM.Iterable", "ES2019"],
"esModuleInterop": true,
"jsx": "react-jsx",
"moduleResolution": "node",
"resolveJsonModule": true,
"target": "ES2019",
"strict": true,
// Remix takes care of building everything in `remix build`.
"noEmit": true
}
}
Can only buildable libraries work with remix ?
Hi, is there any executor being developed yet? Somehow this project doesn't create any target with its own executor after being generated with nx. This makes me relies on package.json to run scripts. I would really appreciate if you guys can eliminate the needs to use package.json, especially since by adding package.json means it adds workspace dependency into yarn.lock. This is problematic for docker builds since this means I need to add unnecessary project just for building
This looks promising: https://www.npmjs.com/package/@nrwl/remix
Official one, right?
Can only buildable libraries work with remix ?
No, I got a classic, non buildable lib based nx project working with remix. You just need to tweek a bit the tsconfig so it correctly resolve the libs. (basically, remix app tsconfig should not have a paths property, so it only extends the root config.)
There is only one small caveat: https://github.com/remix-run/remix/issues/2677 but it's easy to live with that :p
@npirotte https://github.com/remix-run/remix/pull/3085 is now merged, so in the next release https://github.com/remix-run/remix/issues/2677 won't be a problem anymore
As otheres have mentioned, it would be great if we could get some workspace executors for @nrwl/remix
One of the most useful options would be a generatePackageJson
option like in the @nrwl/node:webpack
package
https://nx.dev/packages/node/executors/webpack#generatepackagejson
As I have noticed that the default template, generates a package.json
in the project direcotry, as opossed to hoisting deps to the workspace root.
At the moment it feels a little bit janky and not fully part of the NX ecosystem.
See also https://github.com/nrwl/nx-labs/issues/31 for generating a package.json.
Hello everyone, I used the official @nrwl/remix
generator to create my Remix app within my Nx monorepo. I'm now attempting to deploy the aforementioned Remix app to Vercel, and haven't been able to figure it out. I've tried to deploy from both Vercel CLI and the Vercel git integration, and tried both with and without the rootDirectory
setting (in my case, packages/website/
).
Can anyone point me in the right direction? I am loving the Remix generator and getting to share code with the rest of my monorepo, but so far failing miserably to deploy it. Thank you!
@mocon I don't know the exact config required for deploying Vercel, but I'm sure you can figure out the diff by generating a brand new basic app with npx create-remix@latest
and picking Vercel as the deploy target.
Without sharing any code it's pretty hard to guess where your current setup fails.
Is there an update on the executor part? I'm trying to use Remix now, but it still doesn't come with its own executors.
There is a remix plugin in the nx-labs repo, but there isn't much activity besides some recent commits updating it to remix 1.14. No signs pointing to an official plugin in the nx repo.
That's too bad. I'm checking out Turborepo right now as I really want a monorepo tool, but problems with nx keep piling up.
I too am waiting on an official plugin, however, it's actually not been too bad without it. No real issues, with my libs as esbuild "buildable" libs and then the app as a vanilla app. The targets are just Nx run commands and it works fine. Maybe you could do something like that?
Shortly I will probably convert these to Nx executors and generators but I was waiting on the new dev server stuff from Remix to settle a bit.
My problem is that currently my main reasons for using nx are not solved
So in short I'd like to avoid having to do what's outlined here
@adam-arold I don't fully understand what you mean.
- managing dependencies in 1 file
Isn't this actually one of the benefits of using a monorepo? It's out of scope for this issue in my opinion.
Regarding collection of dependencies and their version, the approach taken in the link you provided seems a bit cumbersome to me. It requires you to manually sync the dependencies in your app with the deps.ts
file. A different approach you could take is to have a minimal package.json for the app(s) like this:
{
"private": true,
"name": "my-app",
"scripts": {
"start": "cross-env NODE_ENV=production node ./server.js"
},
"dependencies": {
"cross-env": "<placeholder>"
},
"engines": {
"node": ">=14"
}
}
and use a custom plugin to generate the package.json during the build of the app. See my example repo here for the code. Feel free to copy (MIT license).
- Automatic integration with the underlying tech with (no extra config is needed)
You're essentially meaning that you're missing an executor which could hide some of the configuration for you? By default, nx can run npm scripts (from a package.json file) or you can always use the nx:run-commands executor in a project.json file, which in my opinion are both not that complicated. See here for more info.
- Integration with other workspace projects
So in short I'd like to avoid having to do what's outlined here
As also explained by @wesleygrimes you can reuse code from libraries (they don't have to be buildable), so which integration are you talking about specifically here?
and use a custom plugin to generate the package.json during the build of the app. See my example repo here for the code. Feel free to copy (MIT license).
@JoepKockelkorn where can I find the part that does this?
you can always use the nx:run-commands
This makes sense, thanks
you can reuse code from libraries
Yeah, this started to work with the latest release!
where can I find the part that does this?
@adam-arold In this file is the executor that collects the dependencies.
Thanks, I'll take a look!
My problem is that currently my main reasons for using nx are not solved
- managing dependencies in 1 file
- Automatic integration with the underlying tech with (no extra config is needed)
- Integration with other workspace projects
So in short I'd like to avoid having to do what's outlined here
@adam-arold how would you add a shared-ui library? I don't like @nrwl/remix remix lib plugin because you have to restart the server on every change in the lib....
@adam-arold how would you add a shared-ui library? I don't like @nrwl/remix remix lib plugin because you have to restart the server on every change in the lib....
@nadiTime The shared-ui library doesn't have to be buildable. It was necessary at first, but isn't anymore.
@JoepKockelkorn I see, it is noted in @nrwl/remix
Note: You must restart the server if you make any changes to your library. Luckily, with Nx cache this operation should be super fast.
I don't like @nrwl/remix remix lib plugin because you have to restart the server on every change in the lib
Note: You must restart the server if you make any changes to your library. Luckily, with Nx cache this operation should be super fast.
Same limitation exists on the @nrwl/rspack plugin as well. I don't know if there's a tracking issue, but hopefully it will be worked out. You can try something like nodemon in the meantime.
@nadiTime @sscotth Please note that restarting is only needed when you configure the shared UI library as 'buildable'. When you use the library generator from @nrwl/remix
this is hardcoded to true unfortunately. But it doesn't have to be, the comment "Remix can only work with buildable libs and yarn/npm workspaces" is no longer valid. So if you use the @nrwl/react
library generator then you can consume the library as normal (via tsconfig path alias) without requiring a restart.
FYI: Buildable libraries shine when the workspace grows in size and the pipeline starts getting bigger. See the docs:
Buildable libraries are mostly used for producing some pre-compiled output that can be directly referenced from an Nx workspace application without the need to again compile it. A typical scenario is to leverage Nxโs incremental building capabilities.
Anyone getting this with the latest @nx/remix
?
~\Documents\nx3 [master +3 ~4 -0 !]> npx nx g @nx/remix:app demo
> NX Generating @nx/remix:application
โ What unit test runner should be used? ยท vitest
Fetching @nx/vite...
Fetching @nx/cypress...
CREATE apps/demo/project.json
UPDATE package.json
CREATE apps/demo/app/root.tsx
CREATE apps/demo/app/routes/index.tsx
CREATE apps/demo/public/favicon.ico
CREATE apps/demo/README.md
CREATE apps/demo/remix.config.js
CREATE apps/demo/remix.env.d.ts
CREATE apps/demo/tsconfig.json
CREATE apps/demo/.gitignore
CREATE apps/demo/package.json
UPDATE nx.json
UPDATE .vscode/extensions.json
CREATE apps/demo/vite.config.ts
CREATE apps/demo/tsconfig.spec.json
CREATE apps/demo/test-setup.ts
CREATE apps/demo-e2e/cypress.config.ts
CREATE apps/demo-e2e/src/e2e/app.cy.ts
CREATE apps/demo-e2e/src/fixtures/example.json
CREATE apps/demo-e2e/src/support/commands.ts
CREATE apps/demo-e2e/src/support/e2e.ts
CREATE apps/demo-e2e/tsconfig.json
CREATE apps/demo-e2e/project.json
CREATE .eslintrc.json
CREATE .eslintignore
CREATE apps/demo-e2e/.eslintrc.json
npm WARN deprecated @npmcli/move-file@1.1.2: This functionality has been moved to @npmcli/fs
added 924 packages, and audited 1365 packages in 1m
312 packages are looking for funding
run `npm fund` for details
found 0 vulnerabilities
~\Documents\nx3 [master +7 ~5 -0 !]> code .\
~\Documents\nx3 [master +7 ~5 -0 !]> nx start demo
> NX Running target start for project demo and 1 task it depends on:
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
> nx run demo:build
Building Remix app in production mode...
โ ๏ธ REMIX FUTURE CHANGE: The behaviors of `CatchBoundary` and `ErrorBoundary` are changing in v2. You can prepare for this change at your convenience with the `v2_errorBoundary` future flag. For instructions on making this change see https://remix.run/docs/en/v1.15.0/ppages/v2#catchboundary-and-errorboundary
โ ๏ธ REMIX FUTURE CHANGE: APIs that provide `formMethod` will be changing in v2. All values will be uppercase (GET, POST, etc.) instead of lowercase (get, post, etc.) You can prepare for this change at your convenience with the `v2_normalizeFormMethod` future flag. For instructions on making this change see https://remix.run/docs/en/v1.15.0/pages/v2#formMethod
โ ๏ธ REMIX FUTURE CHANGE: The route `meta` export signature is changing in v2. You can prepare for this change at your convenience with the `v2_meta` future flag. For instructions on making this change see https://remix.run/docs/en/v1.15.0/pages/v2#meta
โ ๏ธ REMIX FUTURE CHANGE: The route `headers` export behavior is changing in v2. You can prepare for this change at your convenience with the `v2_headers` future flag. For instructions on making this change see https://remix.run/docs/en/v1.17.0/pages/v2#route-headers
โ ๏ธ REMIX FUTURE CHANGE: The `serverModuleFormat` config default option will be changing in v2 from `cjs` to `esm`. You can prepare for this change by explicitly specifying `serverModuleFormat: 'cjs'`. For instructions on making this change see https://remix.run/docs/een/v1.16.0/pages/v2#servermoduleformat
โ ๏ธ REMIX FUTURE CHANGE: The route file convention is changing in v2. You can prepare for this change at your convenience with the `v2_routeConvention` future flag. For instructions on making this change see https://remix.run/docs/en/v1.15.0/pages/v2#file-system-route--convention
TypeError: Cannot read properties of undefined (reading 'data')
at getRelativeDependencyPaths (C:\Users\georgiosd\Documents\nx3\node_modules\@nx\remix\src\utils\create-watch-paths.js:27:25)
at Object.<anonymous> (C:\Users\georgiosd\Documents\nx3\node_modules\@nx\remix\src\utils\create-watch-paths.js:20:16)
at Generator.next (<anonymous>)
at fulfilled (C:\Users\georgiosd\Documents\nx3\node_modules\tslib\tslib.js:164:62)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
Warning: run-commands command "remix build" exited with non-zero status code
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
> NX Running target start for project demo and 1 task it depends on failed
Failed tasks:
- demo:build
Hint: run the command with --verbose for more details.
Submitted a fix here: https://github.com/nrwl/nx-labs/pull/303
I have open here this discussion that I think it is related with this issue https://github.com/nrwl/nx/discussions/18810
@nx/remix
has some functionalities but there is not a build executor like in the nextjs app for example. The package.json is not generated in the build step and consequently the Dockerfile can not be generated in the same way.
There is plan to made a custom build executor in @nx/remix
that encapsulates the required dependencies by the remix app?
Remix has been officially added to the Nx repo and therefore will receive first-party support, similar to our other first-party plugins
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.
Description
Instead of Next.js, I want to be able to use Remix
Motivation
Now that Remix is released, it would be great to use it together with NX.