Quick question: by default you have an ‘apps’ top level folder and a ‘libs’ top level folder… is there anything stopping me from having other app kind top level folders? … e.g.:
I think Nx kinda expects the
libs folders to exit. It might work for most things, however some schematics or future migrations might not work as expected
This PR landed a few days back, it ads support for a different workspace layout. The example in the PR uses a single
packages folder https://github.com/nrwl/nx/commit/a95cba314484465d618b5bc7c0faacd885e8720d
The reason I bring it up is that that PR should give you a fairly good idea where the
libsDir are being used, so you can make an estimate on what you’ll be missing out on
You should keep your apps and libs in their respective folders. But you can nest apps in subfolders as much as you want.
I would do this:
Ah sweet - thanks guys!
- even then, the folders underneath “dashboards” would still need to be unique right? e.g. I can’t have:
/apps /foo /bar /dashboards /foo /bar
No, that structure is fine
nx build foo or
nx build dashboards-foo
so ‘dashboards-foo’ would translate to the ‘dashboards/foo’ directory?
but in nx.json and workspace.json I would surely need to name the projects “dashboard/foo” or “dashboard-foo” ?
or rather, I can/should just name them uniquely in those json files, and point to the right place, and all will be well …
seems to work to have slashes in teh project name
I would keep the naming convention that is used when a you generate a new app. (i.e.
- instead of
/ in the name). I’m pretty sure that was put there for a reason and schematics may expect that convention.
nx generate @nrwl/workspace:application --name=foo --directory=dashboards
Schematic “application” not found in collection “@nrwl/workspace”.
hm. let me try that again
it needs to be a specific framework that you’re using
@nrwl/workspace has a
lib schematic, but not an app
right - i’m rolling my own, since I’m migrating a serverless stack, but no worries, I get the picture… hyphens make more sense than slashes (no doubt bash would throw a wobbly if you put slashes in names)
ps. anyway plans to have workspace.js rather than .json? could make it a lot DRYer if you can reuse bits… just about all my projects have the same lint builder with just name changes… makes manually editing the workspace.json a recipe for typos
(just as an example)
the problem with having a
.js file is it makes statically analyzing a lot more difficult.
you have to actually run the code to know what the values are