next-transpile-modules: How to handle module that don't have package.json or main field (because they don't need to)

  • I HAVE READ THE FAQ AND MY PROBLEM WAS NOT DESCRIBED THERE
  • I WILL GIVE 10$ TO CHARITY IF MY SOLUTION WAS ACTUALLY IN THE README/FAQ

Are you trying to transpile a local package or an npm package?

I am trying to transpile bs-platform, and some reason-* packages.

Describe the bug

When starting next.js, this module crash with the following error:

$ next dev
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
warn  - React 17.0.1 or newer will be required to leverage all of the upcoming features in Next.js 11. Read more: https://err.sh/next.js/react-version
Error: next-transpile-modules - an unexpected error happened when trying to resolve "bs-platform"
Error: Can't resolve 'bs-platform' in '/Users/moox/dev/moox.io'

To Reproduce

Steps to reproduce the behavior (a reproduction is even better):

Just try to include bs-platform. ReScript works by compiling JS where the ReScript files are located. ReScript itself (bs-platform = ReScript Package) have a kind of standard lib that is built-in.

Expected behavior

bs-platform don’t need a package.json main field because you don’t consume this directly. You only directly consume at some files. Yeah it’s “all files” but they are only consumed individually by hitting directly them when included.

For example

image

Setup

  • Next.js version: 10.0.8
  • next-transpile-modules version: 6.3.0
  • Node.js version: 10.22
  • npm/yarn version: yarn v1.22.4
  • Operating System: macOS
  • Webpack 4 or 5: 4

Additional context

It was working with previous version of this module 😦

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 16 (9 by maintainers)

Most upvoted comments

The main field (or exports field) is a necessary thing in order for enhanced-resolve to get the root path of the package you are trying to transpile.

It is not a constrain I am willing to remove, as this is what allowed fixing some otherwise unfixable issues (cf. #115).

I know it may not make sense for some really particular usecases where you never import anything from root, I personally believe this is still a good practice. This is also a small price to pay for something not included in vanilla next.js too.