Standardization of a entrypoints in package.json for other languages.

[atishay]

Problem

npm is used as the package manager for not just the Node JS ecosystem but the Typescript ecosystem as well as the CSS and SASS ecosystems.
The main property is unfortunately tied to JavaScript and there is no official entrypoint for other languages inside of package.json. To support other languages better, we need a new way to standardize language specific entrypoints which can be used by bundlers and compilers to provide a unified experience across languages.

Current Workarounds

There has been some consensus amongst projects like Bootstrap, Tailwind.css and Normalize.css to use the "style" property for CSS. Bootstrap exposes "sass" for the scss version as well as "module" for the ES Module version of bootstrap. Tools like npm-css have come up to solve bundling CSS from these locations.

There seems to be no consensus on the Typescript main property and there have been community requests to solve this problem.

Request

Standardize on language specific entrypoints in the official package.json documentation and provide guidance for compiler and bundlers built over npm to honor those.

[MylesBorins]

Hey @atishay !

Worth mentioning that I helped to create the ESM implementation in Node.js core, so I definitely have a bias here regarding package.exports 😇. I also do standards work at TC39 + W3C, so have a bias regarding standards as well.

Historically use of the package.json for meta data that tools can rely on has been driven more by convention, ecosystem adoption, and implementation rather than standardization. In general, I think that path is honestly the more appropriate way forward with so many different ecosystem relying on the package.json format, as you've pointed out.

The intention in Node.js of using package.exports was to try and formalize package entry points and make a field that could be extended by developer. For examples the following allows for CJS / ESM + browser / node entry points in a package and could be supported by node, webpack, and rollup

{
  "exports": {
    "node": {
      ".": {
        "require": "./lib/index.cjs",
        "import": "./lib/index.mjs"
      }
    },
    "browser": "./lib/index-browser.js"
  }
}

I could very well seeing other environments building on this by introducing a style field. This would be ignored by the node.js loader and could be used by other tools.

It is worth mentioning there is standardization of CSS modules that is being done right now! https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md

Back to your original question though. We could explore standardizing these entry points and patterns, but I'm not 100% sure where the most appropriate venue would be. Perhaps we could spin something up in the WICG to start the discussion... but this would require the various stakeholders that utilize the package.json, including Node.js + Webpack + Rollup + npm + all the projects you mentioned above to be on the same page about what the appropriate venue was, and also respect the standards that were created.

Someone once told me something very wise about ecma262, the standard behind the JavaScript language. "ecma262 is just another implementation of JavaScript that happens to be written in spec text and created in collaboration with multiple vendors." For a standard to be successful we need spec + tests + implementation.

At risk of being pedantic I'm going to step back from defining standards, because what I think you are asking for is finding a way to build ecosystem coalescing around these patterns. The only way to do this is to bring the various stakeholder together, and often a standards organization is a great neutral place to do this. That said we need these stakeholders to want to do this work AND commit to doing it.

Where does npm fit in here? We can't force any projects to implement anything, including node.js. As much as we may want to at times, we can't simply say something is a standard and force the ecosystem to follow suit. What we can do is create great experiences that encourage the ecosystem to coalesce. In particular I'm excited about the work being scoped out in https://github.com/npm/feedback/discussions/13 and npm/roadmap#20 where we will use package.json metadata (and other heuristics) to surface package information to consumers.

Seems like I accidentally wrote an essay, oops. I'm gonna stop and give you some space / time to respond. With the context I've laid out above, what do you think would be appropriate next steps?

[atishay]

I did not purposefully put a solution because I don't know what the right solution should be (I don't see any problem with package.exports in general). Most developers don't care what it is called as long as it does what it needs to.

I am not really sure where https://github.com/npm/feedback/discussions/13 is going and in the discussion on CSS modules WICG/webcomponents#759 I don't see a mention of the entire npm ecosystem where the css code is currently shared. I think the package.json and the npm ecosystem needs to be considered in both the typescript and css discussions. The webpack workaround is disheartening and complicated as you need to enter this manually looking at the fields within package.json of each module.

I thought npm is a good place to have this discussion but I think WICG might be a better place. If you can help carve out a good place for this discussion, I think we can nudge the stakeholders to participate in it and come to a resolution.