Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

comparison with nx #166

Closed
threepointone opened this issue Nov 25, 2020 · 1 comment
Closed

comparison with nx #166

threepointone opened this issue Nov 25, 2020 · 1 comment
Labels
discussion Discussion topic

Comments

@threepointone
Copy link
Contributor

nx is a feature-heavy toolchain for managing monorepos. It's gaining a lot of acceptance; and because they're building a business around it, is also very well supported. This issue isn't meant to be a deep dive into every nx feature, but only some of the key ideas in the context of modular.


e2e: Standardises on cypress for writing and running e2e tests. This is a good idea, we should do this too. (related - #48)

dep-graph: People like this, though it's not clear to me just yet what "business value" it brings. Regardless, it should be something we consider for "modular dashboard" (or whatever we call it.)

affected: This is one of the big features of nx, being able to run builds/lint/test/whatever only on workspaces/modules that have been changes/affected by other changed files. We should definitely work on this (related #147, but we should expand the scope more)

computation caching: related to affected. (related issue: #121)

console: This is dope, and we should look to it when building modular-dashboard.

migrate: Interesting story on upgrades (for nx itself, iiuc). I still firmly believe that we can keep breaking changes to a minimum post-1.0 so it won't be a major concern, but having automated workflows for upgrades sounds very appealing (much like codemods for files)

plugins: Might not be something we need/should do, considering we're trying to be as opinionated as possible.


(This was a quick run through, I'll probably keep updating this list and adding more detail as it comes to light.)

@threepointone threepointone added the discussion Discussion topic label Nov 25, 2020
@matt-d-webb
Copy link
Contributor

console: This is dope, and we should look to it when building modular-dashboard.

Wow, that looks pretty neat. I think they've touched on the correct point here when they say Developers "use the right tool for the job" (or at least try to). Not everything makes sense (or is easy) via the CLI. We should certainly make the correct distinction with our toolset too, having a VS Code plugin has a lot of potential to bring together a number of highly valuable features!

@jpmorganchase jpmorganchase locked and limited conversation to collaborators May 24, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
discussion Discussion topic
Projects
None yet
Development

No branches or pull requests

3 participants