Weird errors building a web:app which consumes js:lib

[ziacik]

It looks like the web babel loader doesn't understand it tries to compile typescript (maybe it's expected to use already built lib's js files from dist and it doesn't for some reason?)

Also, the web:app consuming node:lib works just fine.

The errors are like this:

ERROR in ../../../libs/controls/src/lib/Helpers/platform.ts
Module build failed (from ../../../node_modules/@nrwl/web/src/utils/web-babel-loader.js):
SyntaxError: /home/kolik/Workspaces/resco/web-projects-nx/libs/controls/src/lib/Helpers/platform.ts: Support for the experimental syntax 'flow' isn't currently enabled (1:8):

> 1 | export type Platform = {
    |        ^
  2 | 	name: string;
  3 | 	wheelSupported: boolean;
  4 | 	swipeSupported: boolean;

Add @babel/preset-flow (https://git.io/JfeDn) to the 'presets' section of your Babel config to enable transformation.
If you want to leave it as-is, add @babel/plugin-syntax-flow (https://git.io/vb4yb) to the 'plugins' section to enable parsing.
    at Parser._raise (/home/kolik/Workspaces/resco/web-projects-nx/node_modules/@babel/parser/lib/index.js:569:17)
    at Parser.raiseWithData (/home/kolik/Workspaces/resco/web-projects-nx/node_modules/@babel/parser/lib/index.js:562:17)
    at Parser.expectOnePlugin (/home/kolik/Workspaces/resco/web-projects-nx/node_modules/@babel/parser/lib/index.js:3626:18)
    at Parser.isExportDefaultSpecifier (/home/kolik/Workspaces/resco/web-projects-nx/node_modules/@babel/parser/lib/index.js:14786:16)
    at Parser.maybeParseExportDefaultSpecifier (/home/kolik/Workspaces/resco/web-projects-nx/node_modules/@babel/parser/lib/index.js:14672:14)
    at Parser.parseExport (/home/kolik/Workspaces/resco/web-projects-nx/node_modules/@babel/parser/lib/index.js:14625:29)
    at Parser.parseStatementContent (/home/kolik/Workspaces/resco/web-projects-nx/node_modules/@babel/parser/lib/index.js:13633:27)
    at Parser.parseStatement (/home/kolik/Workspaces/resco/web-projects-nx/node_modules/@babel/parser/lib/index.js:13525:17)
    at Parser.parseBlockOrModuleBlockBody (/home/kolik/Workspaces/resco/web-projects-nx/node_modules/@babel/parser/lib/index.js:14114:25)
    at Parser.parseBlockBody (/home/kolik/Workspaces/resco/web-projects-nx/node_modules/@babel/parser/lib/index.js:14105:10)

[ziacik]

Ok so I compared the generated configs from js:lib and node:lib and what seems to help is adding a .babelrc file (copied from node:lib):

{
	"presets": [["@nrwl/web/babel", { "useBuiltIns": "usage" }]]
}

So now I'm wondering if it's a bug in js:lib generator.

[floroz]

Ok so I compared the generated configs from js:lib and node:lib and what seems to help is adding a .babelrc file (copied from node:lib):

{
	"presets": [["@nrwl/web/babel", { "useBuiltIns": "usage" }]]
}

So now I'm wondering if it's a bug in js:lib generator.

FYI: This step is not necessary if importing the library into an SWC compiled application, for example @nrwl/next:app

[floroz]

@ziacik could you please confirm that you get that error when consuming the library from a @nrwl/react:app?

[adityawarrier]

+1
This happens for a library that I generated via @nrwl/js.
The error pops up when I try and use something exported from that library within one of my applications.

Adding .babelrc file with
{ "presets": [["@nrwl/web/babel", { "useBuiltIns": "usage" }]] }
in the library solves the issue.

[floroz]

because the "@nrwl/web/babel", doesn't have the plugin to transform JSX, you need to use the "@nrwl/react/babel" for the libraries where you have React Components

[sbitproz]

Which makes sense so looking at https://babeljs.io/docs/en/presets/ - is this how I would write the presets?

{
  "presets": [
    [
      "@nrwl/web/babel",
      { "useBuiltIns": "usage" }
    ],[
      "@nrwl/react/babel",
      {
        "runtime": "automatic"
      }
    ]
  ],
  "plugins": [["styled-components", { "pure": true, "ssr": true }]]
}

After generating this workspace with the application + libraries, there's only one .babelrc file - should I be creating one for each library?

[floroz]

if you generate a @nrwl/react:library you can copy and paste the exact .babelrc file, AFAIK @nrwl/react/babel already extends the web plugins, so you don't need to declare both (if you look at the example from the react library, you will see)

[sbitproz]

Thanks for reply.

Ok, let me start again, I had the generated react preset in place - it didn't work. I had similar issues to what had been reported here: #8793 - which directed me to this discussion.

When using the generated .babelrc file with a typescript library

{
  "presets": [
    [
      "@nrwl/react/babel",
      {
        "runtime": "automatic"
      }
    ]
  ],
  "plugins": [["styled-components", { "pure": true, "ssr": true }]]
}

I get the following output

SyntaxError: /home/.../experimental/.../libs/core-data/src/lib/user.service.ts: Unexpected token, expected "," (6:24)

  4 | const getUrl = () => `users/`;
  5 |
> 6 | const getUrlWithId = (id: string) => `users/${id}`;
    |                         ^
  7 |
  8 | export const usersAPI = baseAPI(getUrl, getUrlWithId);

I think you said @floroz

#8793 (comment)

@nrwl/js:library is compiled correctly from SWC application, example @nrwl/next:app but not from web applications or react application.

The .babelrc needs to be added to the @nrwl/js:library default generator

[floroz]

EDIT: just to avoid confusion from others reading, I am not an NX maintainer/contributor, just using NX in my work place so I have experienced the same issue highlighted in this thread

@sbitproz hard to say without seeing a repo where we can reproduce the error, what I would do is the following:

• try generate a new TS only library from scratch and import it into the application, check that it works correctly with the web/babel preset
• try generate a new React library from scratch and import it into the application, check that it works correctly with the react/babel preset

If they work correctly, you might need to regenerate your TS library;
If you have the same error, try generate a new react application from scratch, and check if those two libraries are transformed and compiled correctly.

If you still have issue, I'd recommend creating a public repro where the issue can be reproduced

[floroz]

Further investigation of the issue

[Nick-Lucas]

Same issue, using some common libraries between a NestJS API and React app. The .babelrc tweaks mentioned in this thread initially gave me some nasty webpack errors and I realised one of the libraries was referencing a NodeJS package, so split out the common types and the issue is now sorted. Very frustrating since I was already re-exporting types and consuming the same libraries for weeks now, I just expanded the type exports a little and the house of cards fell over today.

Here's a quick sample of the errors I saw before splitting up the NodeJS dependent library:

WARNING in ../api-types/src/lib/users.ts 4:0-65
export 'AppUserRegistrationRequest' (reexported as 'AppUserRegistrationRequest') was not found in '@inventory/okta-management' (possible exports: Users, isExistingUser, mapUserToAppUser)

WARNING in ../api-types/src/lib/users.ts 4:0-65
export 'AppUserRegistrationResult' (reexported as 'AppUserRegistrationResult') was not found in '@inventory/okta-management' (possible exports: Users, isExistingUser, mapUserToAppUser)

ERROR in ../../node_modules/@okta/okta-sdk-nodejs/src/api-error.js 14:11-26
Module not found: Error: Can't resolve 'util' in '/home/n_lucas/dev/inventory/node_modules/@okta/okta-sdk-nodejs/src'

BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.

If you want to include a polyfill, you need to:
        - add a fallback 'resolve.fallback: { "util": require.resolve("util/") }'
        - install 'util'
If you don't want to include a polyfill, you can use an empty module like this:
        resolve.fallback: { "util": false }

ERROR in ../../node_modules/@okta/okta-sdk-nodejs/src/client.js 13:11-24
Module not found: Error: Can't resolve 'os' in '/home/n_lucas/dev/inventory/node_modules/@okta/okta-sdk-nodejs/src'

I'm still seeing the 2 warnings at the top, which are weird but don't seem to be breaking the build right now.

[tomayrimok]

Hey @Nick-Lucas , I'm facing the same issue and nothing seems to be working.
Did you succeeded to solve this problem?
I've been stuck with this for 2 days or more 😵

[codart1]

I'm facing this issue too, I'm importing a buildable library generated using @nrwl/js:lib and swc compiler.
btw, what is the difference between a library generated using @nrwl/js vs the one generated by @nrwl/workspace 🤔 it makes me confused

[lasharela]

[acroyear]

I too have stumbled into this and no workarounds are working. Basically when i build or run the app, all of the libraries are re-interpreted (in spite of having already built them separately) and they seem to be interpreted with a javascript compiler. When not complaining about flow it gripes about missing ; or , and the like, any time it runs into the : that specifies the type onto param or variable somewhere.

(all libraries were react:lib, and this used rollup for the bundling).

I'm on 15.6.3 so I presume I have the latest patches. I just started this nx project (my older lerna/storybook setup was out of date and i couldn't get js upgrades to work because of incompatibilities i got sick of arguing with). I finally got all the things 'green' in the editor and the libs are able to build, but the app is hitting this every time it tries to reference a file from one of the libs.

[acroyear]

UPDATE - ok, i had 1 library that was js/lib rather than react/lib (my DAO and models, no react dependencies) and this lib did not have a babelrc file. When I copied one over from the react/lib libs, that seemed to do the trick.

[javobal]

so this problem seems to be already fixed but i still stumble on it because i created my js/lib first and later a created a react/app, so the js/lib doesn't have a babelrc. the solution seems to recreate the js/lib using the flag "includeBabelRc" but it is an easy mistake to do if you are new into NX.

Issue: #8793