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
For now, it seems like the main and module fields of the generated package.json file are hardcoded to be the following format:
[package-name].umd.js, and
[package-name].esm.js
There are no ways to customise this, and it may cause issues especially when using the preserveModules: true option. When the entry file is set to be index.ts, for example, the built entry file will still be index.js even though the main/module fields refer to a file named after the package name + module type.
while the file directory in the dist/ folder looks like:
dist/
├── index.js
└── index.d.ts
Motivation
This generally doesn't cause an issue since the consuming application, when encountering a non-existent main or module file, will simply fallback to look for index.js as a fail-safe behavior. However, we should still be allowed to customise the values of these fields.
There are also several use-cases on StackOverflow that highlights this need is not specifically relevant to me, but also a few others:
Description
For now, it seems like the
main
andmodule
fields of the generatedpackage.json
file are hardcoded to be the following format:[package-name].umd.js
, and[package-name].esm.js
There are no ways to customise this, and it may cause issues especially when using the
preserveModules: true
option. When the entry file is set to beindex.ts
, for example, the built entry file will still beindex.js
even though the main/module fields refer to a file named after the package name + module type.The
package.json
references may look like this:Yet, the generated
package.json
looks like this:while the file directory in the
dist/
folder looks like:Motivation
This generally doesn't cause an issue since the consuming application, when encountering a non-existent
main
ormodule
file, will simply fallback to look forindex.js
as a fail-safe behavior. However, we should still be allowed to customise the values of these fields.There are also several use-cases on StackOverflow that highlights this need is not specifically relevant to me, but also a few others:
Suggested Implementation
Reconsider how the
main
andmodule
fields are being written. Right now it is hardcoded to the package name: see lines herenx/packages/web/src/executors/package/package.impl.ts
Lines 302 to 303 in 9d78629
Alternate Implementations
Allow us to define the
main
andmodule
fields at the very least.The text was updated successfully, but these errors were encountered: