hi i m trying out nx a…

3 minute read

hi… i’m trying out nx. as an exercise, i’d like to build an assets site - no react, no angular, just a set of static assets, many of which need to be built from various sources (eg building small pngs from complex svgs). which plugin should i use for this?


there is a<https://nx.dev/angular/plugins/web/overview >@nrwl/web<https://nx.dev/angular/plugins/web/overview plugin> (nx g @nrwl/web:app), that doesn’t bring in any framework, but still supports bundling via the @nrwl/web:build builder..maybe that will help? and you can delete anything extra that you don’t need (like the jest config, e2e tests etc., since you’ll be dealing with mostly images/svgs)
if you don’t need bundling/webpack, and you just want some assets to be copied from the /apps/my-assets folder to dist/apps/my-assets so they can be deployed to some host - there’s always <https://nx.dev/angular/plugins/workspace/builders/run-commands the option to use >run-commands and tell it to do a copy:

"build": { "builder": "@nrwl/workspace:run-commands", "options": { "commands": [ { "command": "cp -R apps/my-assets dist/apps/my-assets" } ] } } not sure how much this helps :smile: but happy to try and understand your use-case more though!!

that helps, thanks. the use case is to deploy a site (eg) <http://assets.example.com assets.example.com> with static assets other sites can rely upon (and browsers can cache), rather than having to bundle them with each of those sites separately

there’d be a mix of truly static assets (eg logos) and built assets (eg pngs at various sizes built from complex svgs). a build step is necessary, but it’s not bundling - it’s processing images in various ways and putting them somewhere for deployment, i guess under dist/apps/my-assets as you say

i must say i’m finding the nx doc to be great on the high-level concepts, but not so great on the details and on helping you make the right decisions

case in point - linting. great, nx lint lints everything. then in reality, each project has an eslintrc file inheriting from a base, but there’s no more details: why that linting config? (it looks pretty opinionated) if i change it, will it survive an upgrade? if i generate two react apps, i now have two independent eslint configs (one for each app) with the same rules: what’s the best way to centralise that config to avoid the duplication + inevitable divergence, without breaking upgrades?

(as a newbie i’m lacking a bunch of history and context, and ranting instead, sorry)

this is great feedback, not randing at all! we’re restructuring our docs a bit now - trying to add a few more guides, and making those guides easier to find. On one hand, we need to answer the pure technical questions “what command do I run to generate a publishable library?“, but a lot of questions are more “monorepo design” oriented - “how should teams deal with breaking changes from other teams”, “strategies for deployment”, “centralising lint configs” (like you said)

some of these are spread out between blog posts, docs and example github repos - so we’re trying to summarise them and bring them in to the docs site, so all these examples of where things could be improved are really appreciated!!

glad to help. what’s the best way to give you feedback like this (i have a background in ux/dx and docs)? I did create an issue on github with my experiences with nx a few weeks ago (slightly different assets concept, and then i got called away onto a different project). sadly that issue didn’t get any traction: https://github.com/nrwl/nx/issues/2891

oh that’s a very nicely written issue! I’ve definitely seen it referenced in a very positive light in discussions on how we can improve our docs - so it’s definitely being looked at, even if more gradually, as we’re prioritising sections in the docs