Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package entry points for different builds #131

Open
RomanMiniv opened this issue Dec 25, 2024 · 1 comment
Open

Package entry points for different builds #131

RomanMiniv opened this issue Dec 25, 2024 · 1 comment

Comments

@RomanMiniv
Copy link
Contributor

Hello,

Intro:

I use webpack 5, typescript and littlejsengine package.

Webpack has 2 configurations for development and production.
The littlejsengine package has an entry point "main": "dist/littlejs.esm.js", so Webpack for any mode uses the specified module when working with this package.

However, the littlejsengine package has several builds for different purposes.
https://github.com/KilledByAPixel/LittleJS?tab=readme-ov-file#builds

Issue:

Using different builds of the littlejsengine package for different modes.

Solution:

In addition to the "main" field, package.json has another field for defining the entry point - "exports". In short, this is a modern version of defining the entry point, which can vary depending on different conditions.
https://nodejs.org/api/packages.html#package-entry-points

Webpack 5 in turn supports optimization conditions
https://webpack.js.org/guides/package-exports/#optimizations

So I suggest extending package.json by adding the field:

"exports": {
  "types": "./dist/littlejs.d.ts",
  "production": "./dist/littlejs.esm.min.js",
  "default": "./dist/littlejs.esm.js"
},

https://webpack.js.org/guides/package-exports/#providing-devtools-or-production-optimizations

Why not like this?

"exports": {
  "types": "./dist/littlejs.d.ts",
  "development": "./dist/littlejs.esm.js",
  "default": "./dist/littlejs.esm.min.js"
},

Because the entry point is defined in the main field as a development build, which includes debug in particular. Also, the development and production fields are conditions that Webpack supports, other bundlers may not support them, so we keep the original behavior.

Summary

  1. By adding the exports field to package.json, we get automatic support for builds for Webpack based on its mode field.

  2. For other bundlers that may not support the custom development and production fields like Webpack does, they can still be processed in the code itself using environment variables, for example:

if (process.env.NODE_ENV !== 'development') {
  import LittleJS from "littlejsengine/production";
} else {
  import LittleJS from "littlejsengine";
}

https://webpack.js.org/guides/package-exports/#with-nodejs-runtime-detection

  1. I think it's better to leave the entry point in "main" for older versions of Node.js, in new versions if the "main" and "exports" fields are defined, preference is given to "exports" where it is supported.
    https://nodejs.org/api/packages.html#package-entry-points

In case of agreement, I can make a PR for this.

@KilledByAPixel
Copy link
Owner

Hey, thanks so much for looking into that. It sounds like a good plan to me, I was wondering about how to accomplish this for release builds.

Feel free to go ahead and make the PR!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants