n00b question When I bu…

n00b question: When I build a node app in Nx, how do I get node to understand the @project/my-lib paths in my require statements? My only real exposure to node has been building Azure Functions, and I’ve always used relative paths in my requires. I assumed Nx would have taken care of turning @project/my-lib into relative paths for me on build. Am I missing something? (Clearly.) I’m trying to turn an Nx-generated node app into an Azure Functions app, so, for all I know, maybe Nx is supposed to do this for me and I’ve broken the build command/system.

Responses:

nx uses the tsconfig.json to map the paths of the libraries

what node builder are you trying to use?

How are you running your app?

um… I was using the @nrwl/node:build, then I started trying to make my own because Azure Functions has some very different assumptions about how an application is structured. Is that what you’re asking?

I’ll be uploading it to Azure Functions. When I deployed it using the VS Code extension for Azure Functions, Functions couldn’t find the libs in the require statements. When I build the app using nx build my-app, I still see @project/my-lib in the require statements, so I haven’t even gotten as far as uploading that to Azure Functions.

Sorry guys, my only real experience with this stuff is authoring an Azure Functions app in VS Code and deploying it using the built in tooling there. I’m way out of my depth here.

Azure Functions wants each function in the app to be an index.js file in its own directory, off the root of the project, with no main.js or anything like that in the root. So the node builder in Nx isn’t exactly what I need, which is why I started building my own builder, based on the official node one.

I can see all the path mapping in the tsconfig.json in the workspace root, but I don’t know how that turns into require statements that a node-based runtime can resolve.

Ultimately, what I’d really like is to have all the libs brought into the app, inside a lib folder off the root, and all the functions sitting in their own folders, also off the root.

Convincing tsc to not mirror apps/app-name/function-folder in the root of the built project is my next issue, so if I have to throw additional tooling at the require statements, I’d like it to be tooling I can also use to re-work the folder structure of the built application.

FunctionApp | - host.json | - MyFirstFunction | | - function.json | | - index.js | - MySecondFunction | | - function.json | | - index.js | - libs

So, when I build the app, import { createEvent } from “@cosmos/azure-functions-shared” will need to become import { createEvent } from “../libs/azure-functions-shared”

what happens if you set buildLibsFromSource to true and externalDependencies to "none"?

in your builder options

Hrm. I don’t see any change in behaviour. Everything still compiles fine, I get an apps folder with the app, a libs folder with the libs. But, the compiled .js files still have statements like:

import { createEvent } from “@cosmos/azure-functions-shared”;

Should I be seeing paths that have been changed to relative paths? Am I wrong to expect to see: import { createEvent } from “../../../libs/azure-functions-shared”;

hmm interesting… when i look at the compiled main.js for my node app, i see that libs are imported relative with like libs/node-lib/src/index.ts etc

but only as webpack comments

i haven’t added webpack to any of my tooling. should i have?

This is probably my bad. Because I don’t know what I’m doing,

I based my custom builder on the node “package” builder from nx/packages/node/src/builders/, rather than basing it on “build”. (Package seemed closer to what I wanted.)

When I look at those two builders, I see webpack related stuff in build which isn’t in package.

Is webpack responsible for rewriting those paths when the app is built?

yea

ok, so i’m missing an entire part of the build process

i thought you were using @nrwl/node:build :open_mouth:

switch to that

i think i said i was. i thought i was. yesterday was a long day. :unamused:

package should be used for like deploying to npm where it’s just a straight up compile from typescript to javascript

gotcha. i’m gonna rip out my custom builder, replace it with @nrwl/node:build, and minimally modify that to remove/replace the node assumptions with azure functions assumptions (no “main” file, for example).

thanks for your help. sorry for wasting your time.

hey no worries :smile:

I’ve got a build working using @nrwl/node:build and a custom webpack config. Thanks for pointing me in the right direction, and the tip about buildLibsFromSource and externalDependencies.