You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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
By adding the exports field to package.json, we get automatic support for builds for Webpack based on its mode field.
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";
}
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.
The text was updated successfully, but these errors were encountered:
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:
https://webpack.js.org/guides/package-exports/#providing-devtools-or-production-optimizations
Why not like this?
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
By adding the exports field to package.json, we get automatic support for builds for Webpack based on its mode field.
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:
https://webpack.js.org/guides/package-exports/#with-nodejs-runtime-detection
https://nodejs.org/api/packages.html#package-entry-points
In case of agreement, I can make a PR for this.
The text was updated successfully, but these errors were encountered: