Option to disable webpack entirely in @nrwl/node

[JonathanWilbur]

Description

Option to disable webpack entirely in @nrwl/node.

Motivation

I am having a problem getting dynamic imports to work the way I want with Webpack. There is no good solution to this. I would like to entirely skip webpack.

[JonathanWilbur]

To elaborate on this issue, I have this code:

import * as path from "path";

const PACKAGE_NAME = "@wildboar/c";

async function main () {
  const mod = await import(PACKAGE_NAME);
  mod.default();
}

main();

...which compiles to this:

"use strict";

Object.defineProperty(exports, "__esModule", { value: true });
const tslib_1 = __webpack_require__(/*! tslib */ "./node_modules/tslib/tslib.es6.js");
const path = __webpack_require__(/*! path */ "path");
const PACKAGE_NAME = "@wildboar/c";
function main() {
    return tslib_1.__awaiter(this, void 0, void 0, function* () {
        const mod = yield Promise.resolve().then(() => __webpack_require__("./apps/appy/src sync recursive")(PACKAGE_NAME));
        mod.default();
    });
}
main();

I looked up the API for this __webpack_require__ function, but that was not particularly informative. As you can see, it appears to recursively search under ./apps/appy/src for that given package name. The problem is that this package will definitely not be under this directory. It will be totally external. I have tried to prevent Webpack from mangling these file names with webpackIgnore comments, but that does not work. I would prefer to skip webpack entirely if I can.

[JonathanWilbur]

I believe these lines specifically need to change, but I do not know exactly what return type this function is supposed to have:

https://github.com/nrwl/nx/blob/c41968648a7874c0a03e5523048fa19bf3066011/packages/node/src/executors/build/build.impl.ts#L89-L102

[JonathanWilbur]

Here is the outstanding Webpack issue. It seems like there is not currently any movement in fixing this. It would be nice if Webpack would fix this, but I think Nx should implement the ability to disable Webpack anyway; I imagine there are others out there having a need for it.

[JonathanWilbur]

Actually, I believe this might be (partly) resolved by updating to Webpack 5. I see that Nx uses Webpack 4, and it looks like Webpack 4 does not support magic comments like /* webpackIgnore: true */ which might fix the issue. I don't quite know how to force my local Nx to use Webpack 5 for testing purposes, though..

[Brian-McBride]

You can compile directly with tsc. Something like tsc --project ./apps/yourapp/tsconfig.app.json

Or, use whatever. Rollup, Parcel, etc... Just remember that you need to point to the correct "project" typescript config file. The other thing I noticed that the Node builder does is that it copies over the assets directory and also, in some app cases, swaps out that environment file (although, it is argued that environments should be set at the container level, not the code level)

I am not saying you should use this (this isn't a plug). I started building out a builder for Nx to use esbuild. https://www.npmjs.com/package/@anatine/esbuildnx

Just sharing that because, maybe, it might offer some insights on how I augment a node project in Nx to use a different builder. Writing your own plugins isn't super easy (yet), but the new @nrwl/devkit is a huge step in the right direction. My plugin is a little complex in that it runs both esbuild and tsc (esbuild doesn't typecheck, so I run that in parallel for type checking output).

If you were interested in using a tool like Rollup or Parcel or even rolling your own Webpack 5 builder, the executors can almost be as easy as just creating an async function that does the work you asked for. Just generate yourself a tool lib and experiment in your current project. I think you can start with:

nx generate @nrwl/workspace:workspace-generator --name=<YOUR BUILDER NAME> --dry-run

Install @nrwl/devkit and check out the plugin docs: https://nx.dev/latest/node/nx-plugin/overview

Executor doc link: https://nx.dev/latest/node/core-concepts/nx-devkit#executors

[JonathanWilbur]

That's awesome! I never knew about ESBuild. It looks like the tool for me, just looking at the stats on how much faster it is!

[Brian-McBride]

That's awesome! I never knew about ESBuild. It looks like the tool for me, just looking at the stats on how much faster it is!

If you end up using my esbuildnx, keep in mind that I was making it to package Node server files. I really loathe copying the entire node_modules into every service I deploy, filling my docker image with tons of client-side modules. Also, treeshaking back-end services is pretty cool.

That said, it should work with client apps too. Well, esbuild works with ReactJS and vanilla. Vue and Angular might have issues, not sure. Please feel free to add in pull requests. I'm slammed for a couple weeks, but I'll be adding in the asset support and also creating a list of modules that can't be bundled by esbuild. You'll notice in that case, I copy over those packages into the dist directory node_modules file.

Anyway, point is, it's not too crazy hard to build your own executor. Looking at the Nx source code for examples is harder because they mix in the new and old way. Plus, they reference helper libs that are part of the Nx source code, but not always exposed in external packages. The team should seriously consider making sure that all the helper functions they create for themselves are part of the devkit bundle.

[github-actions[bot]]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. If we missed this issue please reply to keep it active. Thanks for being a part of the Nx community! 🙏

[github-actions[bot]]

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.